- 20 Sep, 2019 9 commits
-
-
Ville Syrjälä authored
Pull the code for computing the limited color range setting into a small helper. We'll add a bit more to it later. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-5-ville.syrjala@linux.intel.comReviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
-
Ville Syrjälä authored
We're configuring the AVI infoframe quantization range bits as if we're always transmitting RGB pixels. Let's fix this so that we correctly indicate limited range YCC quantization range when transmitting YCbCr instead. Signed-off-by:
-
Ville Syrjälä authored
Looks like we're currently setting the MSA to xvYCC BT.709 instead of the YCbCr BT.601 claimed by the comment. But even that comment is wrong since we configure the CSC matrix to BT.709. Let's remove the bogus statement from the comment and fix the MSA to indicate YCbCr BT.709 so that it matches the actual pixel data we're transmitting. Signed-off-by:
-
Anusha Srivatsa authored
Make both GuC and HuC to use "." as the separator. Hardcode the separator in MAKE_UC_FW_PATH. Remove the usage of "ver" from HuC. The current convention being: <platform>_<g/h>uc_<major>.<minor>.patch.bin Update the versions of HuC being loaded of the platforms. SKL - v2.0.0 BXT - v2.0.0 KBL - v4.0.0 GLK - v4.0.0 CFL - KBL v4.0.0 ICL - v9.0.0 CML - v4.0.0 v2: Remove the separator parameter altogether from __MAKE_UC_FW_PATH.(Daniele) - Squash all firmware update patches (Daniele) v3: s/huc/HuC - Correct the order of platforms - Change REVID of cml to 5(Michal) - Code space changes in huc_def (Daniele) Suggested-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Chris Wilson authored
Our sanitychecks indicate that while this register is context saved/restore, the HW does not preserve this bit within the register -- it likely doesn't exist, or one of those mythical bits that the architects insist does something despite all appearances to the contrary. For reference, SAMPLER_MODE is already in i915_reg.h as GEN10_SAMPLER_MODE and is being setup in icl_ctx_workarounds_init() as opposed to the chosen location here of rcs_engine_wa_init). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111754 Fixes: 7f0cc34b ("drm/i915/tgl: Implement Wa_1406941453") Testcase: igt/i915_selftest/live_workarounds Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190920081254.18389-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
As not only is the signal->timeline volatile, so will be acquiring the timeline's HWSP. We must first carefully acquire the timeline from the signaling request and then lock the timeline. With the removal of the struct_mutex serialisation of request construction, we can have multiple timelines active at once, and so we must avoid using the nested mutex lock as it is quite possible for both timelines to be establishing semaphores on the other and so deadlock. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we need to take a walk back along the signaler timeline to find the fence before upon which we want to wait, we need to lock that timeline to prevent it being modified as we walk. Similarly, we also need to acquire a reference to the earlier fence while it still exists! Though we lack the correct locking today, we are saved by the overarching struct_mutex -- but that protection is being removed. v2: Tvrtko made me realise I was being lax and using annotations to ignore the AB-BA deadlock from the timeline overlap. As it would be possible to construct a second request that was using a semaphore from the same timeline as ourselves, we could quite easily end up in a situation where we deadlocked in our mutex waits. Avoid that by using a trylock and falling back to a normal dma-fence await if contended. v3: Eek, the signal->timeline is volatile and must be carefully dereferenced to ensure it is valid. Signed-off-by:
-
Chris Wilson authored
The request->timeline is only valid until the request is retired (i.e. before it is completed). Upon retiring the request, the context may be unpinned and freed, and along with it the timeline may be freed. We therefore need to be very careful when chasing rq->timeline that the pointer does not disappear beneath us. The vast majority of users are in a protected context, either during request construction or retirement, where the timeline->mutex is held and the timeline cannot disappear. It is those few off the beaten path (where we access a second timeline) that need extra scrutiny -- to be added in the next patch after first adding the warnings about dangerous access. One complication, where we cannot use the timeline->mutex itself, is during request submission onto hardware (under spinlocks). Here, we want to check on the timeline to finalize the breadcrumb, and so we need to impose a second rule to ensure that the request->timeline is indeed valid. As we are submitting the request, it's context and timeline must be pinned, as it will be used by the hardware. Since it is pinned, we know the request->timeline must still be valid, and we cannot submit the idle barrier until after we release the engine->active.lock, ergo while submitting and holding that spinlock, a second thread cannot release the timeline. v2: Don't be lazy inside selftests; hold the timeline->mutex for as long as we need it, and tidy up acquiring the timeline with a bit of refactoring (i915_active_add_request) Signed-off-by:
-
Chris Wilson authored
Before we execute a batch, we must first issue any and all TLB invalidations so that batch picks up the new page table entries. Tigerlake's preparser is weakening our post-sync CS_STALL inside the invalidate pipe-control and allowing the loading of the batch buffer before we have setup its page table (and so it loads the wrong page and executes indefinitely). The igt_cs_tlb indicates that this issue can only be observed on rcs, even though the preparser is common to all engines. Alternatively, we could do TLB shootdown via mmio on updating the GTT. By inserting the pre-parser disable inside EMIT_INVALIDATE, we will also accidentally fixup execution that writes into subsequent batches, such as gem_exec_whisper and even relocations performed on the GPU. We should be careful not to allow this disable to become baked into the uABI! The issue is that if userspace relies on our disabling of the HW optimisation, when we are ready to enable that optimisation, userspace will then be broken... Testcase: igt/i915_selftests/live_gtt/igt_cs_tlb Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111753Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919151811.9526-1-chris@chris-wilson.co.uk
-
- 19 Sep, 2019 9 commits
-
-
Ville Syrjälä authored
Modern platforms allow the transcoders hdisplay/vdisplay to exceed the planes' max resolution. This has the nasty implication that modes on the connectors' mode list may not be usable when the user asks for a fullscreen plane. Seeing as that is the most common use case it seems prudent to filter out modes that don't allow for fullscreen planes to be enabled. Let's do that in the connetor .mode_valid() hook so that normally such modes are kept hidden but the user is still able to forcibly specify such a mode if they know they don't need fullscreen planes. This is in line with ealier policies regarding certain clock limits. The idea is to prevent the casual user from encountering a mode that would fail under typical conditions, but allow the expert user to force things if they so wish. Maybe in the future we should consider automagically using two planes when one can't cover the entire screen? Wouldn't be a great match for the current uapi with explicit planes though, but I guess no worse than using two pipes (which we apparently have to in the future anyway). Either that or we'd have to teach userspace to do it for us. v2: Fix icl+ max plane heigth (Manasi) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Leho Kraav <leho@kraav.com> Cc: Sean Paul <sean@poorly.run> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The officially validated plane width limit is 4k on skl+, however we already had people using 5k displays before we started to enforce the limit. Also it seems Windows allows 5k resolutions as well (though not sure if they do it with one plane or two). According to hw folks 5k should work with the possible exception of the following features: - Ytile (already limited to 4k) - FP16 (already limited to 4k) - render compression (already limited to 4k) - KVMR sprite and cursor (don't care) - horizontal panning (need to verify this) - pipe and plane scaling (need to verify this) So apart from last two items on that list we are already fine. We should really verify what happens with those last two items but I don't have a 5k display on hand atm so it'll have to wait. In the meantime let's just bump the limit back up to 5k since several users have already been using it without apparent issues. At least we'll be no worse off than we were prior to lowering the limits. Cc: stable@vger.kernel.org Cc: Sean Paul <sean@poorly.run> Cc: José Roberto de Souza <jose.souza@intel.com> Tested-by:
Leho Kraav <leho@kraav.com> Fixes: 372b9ffb ("drm/i915: Fix skl+ max plane width") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111501Signed-off-by:
Sean Paul <sean@poorly.run>
-
Michel Thierry authored
Enable Small PL for power benefit. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-18-lucas.demarchi@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20190726000226.26914-4-lucas.demarchi@intel.com
-
Radhakrishna Sripada authored
Disable CPS aware color pipe by setting chicken bit. BSpec: 52890 HSDES: 1409142259 v2: Move WA to ctx WA's(Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190909231445.23815-1-radhakrishna.sripada@intel.comReviewed-by:
-
Matt Roper authored
The MCC hpd table is just a subset of the ICP table; we can eliminate it and use the ICP table everywhere. The extra pins in the table won't be a problem for MCC since we still supply an appropriate hotplug trigger mask anywhere the pin table is used. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Matt Roper authored
We generally assume future platforms will inherit the behavior of the most recent platforms, so update our DDC pin mapping defaults to match how ICP/TGP behave (i.e., pins starting from GMBUS_PIN_1_BXT for combo PHY's and pins starting from GMBUS_PIN_9_TC1_ICP for TC PHY's). MCC's non-standard handling of combo PHY C seems like a platform-specific quirk that is unlikely to be duplicated on future platforms, so continue handling it as a special case. Without this change, future platforms would default to gen4-style pin mapping which is almost certainly not what we'll want. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Chris Wilson authored
Check that we are correctly invalidating the TLB at the start of a batch after updating the GTT. v2: Comments and hold the request reference while spinning Signed-off-by:
-
Chris Wilson authored
When using virtual engines, the rq->engine is not stable until we hold the engine->active.lock (as the virtual engine may be exchanged with the sibling). Since commit 22b7a426 ("drm/i915/execlists: Preempt-to-busy") we may retire a request concurrently with resubmitting it to HW, we need to be extra careful to verify we are holding the correct lock for the request's active list. This is similar to the issue we saw with rescheduling the virtual requests, see sched_lock_engine(). Or else: <4> [876.736126] list_add corruption. prev->next should be next (ffff8883f931a1f8), but was dead000000000100. (prev=ffff888361ffa610). <4> [876.736136] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 <4> [876.736137] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether usbnet mii snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth ecdh_generic ecc [last unloaded: i915] <4> [876.736154] CPU: 2 PID: 21 Comm: ksoftirqd/2 Tainted: G U 5.3.0-CI-CI_DRM_6898+ #1 <4> [876.736156] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4> [876.736157] RIP: 0010:__list_add_valid+0x4d/0x70 <4> [876.736159] Code: c3 48 89 d1 48 c7 c7 20 33 0e 82 48 89 c2 e8 4a 4a bc ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 70 33 0e 82 e8 33 4a bc ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 c0 33 0e 82 e8 <4> [876.736160] RSP: 0018:ffffc9000018bd30 EFLAGS: 00010082 <4> [876.736162] RAX: 0000000000000000 RBX: ffff888361ffc840 RCX: 0000000000000104 <4> [876.736163] RDX: 0000000080000104 RSI: 0000000000000000 RDI: 00000000ffffffff <4> [876.736164] RBP: ffffc9000018bd68 R08: 0000000000000000 R09: 0000000000000001 <4> [876.736165] R10: 00000000aed95de3 R11: 000000007fe927eb R12: ffff888361ffca10 <4> [876.736166] R13: ffff888361ffa610 R14: ffff888361ffc880 R15: ffff8883f931a1f8 <4> [876.736168] FS: 0000000000000000(0000) GS:ffff88849fd00000(0000) knlGS:0000000000000000 <4> [876.736169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [876.736170] CR2: 00007f093a9173c0 CR3: 00000003bba08005 CR4: 0000000000760ee0 <4> [876.736171] PKRU: 55555554 <4> [876.736172] Call Trace: <4> [876.736226] __i915_request_submit+0x152/0x370 [i915] <4> [876.736263] __execlists_submission_tasklet+0x6da/0x1f50 [i915] <4> [876.736293] ? execlists_submission_tasklet+0x29/0x50 [i915] <4> [876.736321] execlists_submission_tasklet+0x34/0x50 [i915] <4> [876.736325] tasklet_action_common.isra.5+0x47/0xb0 <4> [876.736328] __do_softirq+0xd8/0x4ae <4> [876.736332] ? smpboot_thread_fn+0x23/0x280 <4> [876.736334] ? smpboot_thread_fn+0x6b/0x280 <4> [876.736336] run_ksoftirqd+0x2b/0x50 <4> [876.736338] smpboot_thread_fn+0x1d3/0x280 <4> [876.736341] ? sort_range+0x20/0x20 <4> [876.736343] kthread+0x119/0x130 <4> [876.736345] ? kthread_park+0xa0/0xa0 <4> [876.736347] ret_from_fork+0x24/0x50 <4> [876.736353] irq event stamp: 2290145 <4> [876.736356] hardirqs last enabled at (2290144): [<ffffffff8123cde8>] __slab_free+0x3e8/0x500 <4> [876.736358] hardirqs last disabled at (2290145): [<ffffffff819cfb4d>] _raw_spin_lock_irqsave+0xd/0x50 <4> [876.736360] softirqs last enabled at (2290114): [<ffffffff81c0033e>] __do_softirq+0x33e/0x4ae <4> [876.736361] softirqs last disabled at (2290119): [<ffffffff810b815b>] run_ksoftirqd+0x2b/0x50 <4> [876.736363] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 <4> [876.736364] ---[ end trace 3e58d6c7356c65bf ]--- <4> [876.736406] ------------[ cut here ]------------ <4> [876.736415] list_del corruption. prev->next should be ffff888361ffca10, but was ffff88840ac2c730 <4> [876.736421] WARNING: CPU: 2 PID: 5490 at lib/list_debug.c:53 __list_del_entry_valid+0x79/0x90 <4> [876.736422] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether usbnet mii snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth ecdh_generic ecc [last unloaded: i915] <4> [876.736433] CPU: 2 PID: 5490 Comm: i915_selftest Tainted: G U W 5.3.0-CI-CI_DRM_6898+ #1 <4> [876.736435] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4> [876.736436] RIP: 0010:__list_del_entry_valid+0x79/0x90 <4> [876.736438] Code: 0b 31 c0 c3 48 89 fe 48 c7 c7 30 34 0e 82 e8 ae 49 bc ff 0f 0b 31 c0 c3 48 89 f2 48 89 fe 48 c7 c7 68 34 0e 82 e8 97 49 bc ff <0f> 0b 31 c0 c3 48 c7 c7 a8 34 0e 82 e8 86 49 bc ff 0f 0b 31 c0 c3 <4> [876.736439] RSP: 0018:ffffc900003ef758 EFLAGS: 00010086 <4> [876.736440] RAX: 0000000000000000 RBX: ffff888361ffc840 RCX: 0000000000000002 <4> [876.736442] RDX: 0000000080000002 RSI: 0000000000000000 RDI: 00000000ffffffff <4> [876.736443] RBP: ffffc900003ef780 R08: 0000000000000000 R09: 0000000000000001 <4> [876.736444] R10: 000000001418e4b7 R11: 000000007f0ea93b R12: ffff888361ffcab8 <4> [876.736445] R13: ffff88843b6d0000 R14: 000000000000217c R15: 0000000000000001 <4> [876.736447] FS: 00007f4e6f255240(0000) GS:ffff88849fd00000(0000) knlGS:0000000000000000 <4> [876.736448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [876.736449] CR2: 00007f093a9173c0 CR3: 00000003bba08005 CR4: 0000000000760ee0 <4> [876.736450] PKRU: 55555554 <4> [876.736451] Call Trace: <4> [876.736488] i915_request_retire+0x224/0x8e0 [i915] <4> [876.736521] i915_request_create+0x4b/0x1b0 [i915] <4> [876.736550] nop_virtual_engine+0x230/0x4d0 [i915] Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111695Signed-off-by:
-
Daniele Ceraolo Spurio authored
Our assumption that the we can ask the HW to lock the SFC even if not currently in use does not match the HW commitment. The expectation from the HW is that SW will not try to lock the SFC if the engine is not using it and if we do that the behavior is undefined; on ICL the HW ends up to returning the ack and ignoring our lock request, but this is not guaranteed and we shouldn't expect it going forward. Also, failing to get the ack while the SFC is in use means that we can't cleanly reset it, so fail the engine reset in that scenario. v2: drop rmw change, keep the log as debug and handle failure (Chris), improve comments (Tvrtko). Reported-by:Owen Zhang <owen.zhang@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Acked-by:
-
- 18 Sep, 2019 2 commits
-
-
Chris Wilson authored
A few times in CI, we have detected a GPU hang on our Haswell GT2 systems with the characteristic IPEHR of 0x780c0000. When the PSMI w/a was first introducted, it was applied to all Haswell, but later on we found an erratum that supposedly restricted the issue to GT1 and so constrained it only be applied on GT1. That may have been a mistake... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111692 Fixes: 167bc759 ("drm/i915: Restrict PSMI context load w/a to Haswell GT1") References: 2c550183 ("drm/i915: Disable PSMI sleep messages on all rings around context switches") Signed-off-by:
-
Matt Roper authored
The CMP PCH ID we have in the driver is correct for the CML-U machines we have in our CI system, but the CML-S and CML-H CI machines appear to use a different PCH ID, leading our driver to detect no PCH for them. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> References: 729ae330 ("drm/i915/cml: Introduce Comet Lake PCH") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461Signed-off-by:
-
- 17 Sep, 2019 2 commits
-
-
Chris Wilson authored
On Tigerlake, MI_SEMAPHORE_WAIT grew an extra dword, so be sure to update the length field and emit that extra parameter and any padding noop as required. v2: Define the token shift while we are adding the updated MI_SEMAPHORE_WAIT v3: Use int instead of bool in the addition so that readers are not left wondering about the intricacies of the C spec. Now they just have to worry what the integer value of a boolean operation is... Signed-off-by:
-
Chris Wilson authored
If we try to clear, or even set, a bit in the register that doesn't change the register state; skip the write. There's a slight danger in that the register acts as a latch-on-write, but I do not think we use a rmw cycle with any such latch registers. Suggested-by:
-
- 16 Sep, 2019 7 commits
-
-
Chris Wilson authored
Include the active context register state when dumping the engine. Suggested-by:
-
Jani Nikula authored
Stop setting ->pipe_mask to zero when display is disabled, allowing us to have different code paths for not actually having display hardware, and having display hardware disabled. This lets us develop those two avenues independently. There are no functional changes for when there is no display. However, all uses of for_each_pipe() and for_each_pipe_masked() will start running for the disabled display case. Put one of the more significant ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases should not be hit with disabled display, or they seem benign. Fingers crossed. All in all, this might not be the ideal solution. In fact we may have had something along the lines of this in the past, but we ended up conflating the two cases. Possibly even by recommendation by yours truly; I did not dare dig up that part of the history. But the perfect is the enemy of the good, this is a straightforward change, and lets us get actual work done in both fronts without interfering with each other. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190916092901.31440-1-jani.nikula@intel.com
-
Ville Syrjälä authored
Clean up the mess with the drm vs. intel types in intel_crtc_atomic_check() and rename varibles accordingly. Reviewed-by:
-
Ville Syrjälä authored
Exfiltrate the cdclk code from intel_modeset_checks() into intel_modeset_calc_cdclk(). Reviewed-by:
-
Ville Syrjälä authored
Bspec says that glk+ max downscale factor is <3.0 for all pixel formats. Older platforms had a max of <2.0 for NV12. Update the code to deal with this. Reviewed-by:
-
Ville Syrjälä authored
There's a helper in drm_fourcc.h these days to check of we're dealing with a two plane YUV format. Make use if it. Also s/plane/color_plane/ in skl_plane_relative_data_rate() to reduce the confusion. Reviewed-by:
-
Jani Nikula authored
Prepare for making a distinction between not having display and having disabled display. Add INTEL_DISPLAY_ENABLED() and use it where HAS_DISPLAY() is used after intel_device_info_runtime_init(). This is initially duplication, as disabling display still leads to ->pipe_mask = 0 and HAS_DISPLAY() being false. Note that ever since i915.display_disable was introduced, it has not affected PCH detection even if it uses HAS_DISPLAY(), as display disable happens after that. Since INTEL_DISPLAY_ENABLED() will not make sense unless HAS_DISPLAY() is true, include a warning for catching misuses making decisions on INTEL_DISPLAY_ENABLED() when HAS_DISPLAY() is false. v2: Remove INTEL_DISPLAY_ENABLED() check from intel_detect_pch() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 13 Sep, 2019 8 commits
-
-
Mika Kuoppala authored
We think that we got rc6 problems sorted out. Flip the switch and let CI expose our tendency to naive optimism. Signed-off-by:
-
Michel Thierry authored
The media ranges extend beyond what gen11 gives so we can't piggypack on gen11 ranges, even on read side. Introduce a table for gen12 and accessors for it. v2: correctly implement gen12_fwtable_write/read (Daniele) v3: update with ranges from bspec. v4: avoid GEN11_NEEDS_FORCEWAKE (Mika) v5: bspec ref (Daniele) BSpec: 52078 Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Daniele noticed new render ranges in Gen11 fw table. Bspec: 18331 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Chris Wilson authored
More pruning away of features until we have a stable system and a basis for debugging what's missing. v2: Fixup vdbox/vebox fusing Signed-off-by:
-
Chris Wilson authored
While srcu may use an integer tag, it does not exclude potential error codes and so may overlap with our own use of -EINTR. Use a separate outparam to store the tag, and report the error code separately. Fixes: 2caffbf1 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") Signed-off-by:
-
Manasi Navare authored
On ICL+, the max supported plane height is 4320, so bump it up To support 4320, we need to increase the number of bits used to read plane_height to 13 as opposed to older 12 bits. v4: * Adjust the width mask also since extra bits are mbz (Ville) v3: * Use 0xffff for mask as extra bits are mbz (Ville) v2: * ICL plane height supported is 4320 (Ville) * Add a new line between max width and max height (Jose) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Manasi Navare authored
On ICL+, the vertical limits for the transcoders are increased to 8192 and horizontal limits are bumped to 16K so bump up limits in intel_mode_valid() v4: * Increase the hdisplay to 16K (Ville) v3: * Supported starting ICL (Ville) * Use the higher limits from TRANS_VTOTAL register (Ville) v2: * Checkpatch warning (Manasi) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
As we remove the struct_mutex protection from around the vma pinning, counters need to be atomic and aware that there may be multiple threads simultaneously active. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913064200.24297-1-chris@chris-wilson.co.uk
-
- 12 Sep, 2019 3 commits
-
-
Chris Wilson authored
Keep the engine awake to ensure that we don't inject any pm-idle requests. References: https://bugs.freedesktop.org/show_bug.cgi?id=111108Signed-off-by:
-
Arkadiusz Hiler authored
Without it we get: Unclaimed read from register 0x1e1110 WARNING: CPU: 2 PID: 1029 at drivers/gpu/drm/i915/intel_uncore.c:1101 __unclaimed_reg_debug+0x40/0x50 [i915] Call Trace: fwtable_read32+0x233/0x300 [i915] i915_interrupt_info+0xa73/0xd60 [i915] seq_read+0xdb/0x3c0 full_proxy_read+0x51/0x80 vfs_read+0x9e/0x160 ksys_read+0x8f/0xe0 do_syscall_64+0x55/0x1c0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109824Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
-
Chris Wilson authored
We see failures where the context continues executing past a preemption event, eventually leading to situations where a request has executed before we have event submitted it to HW! It seems like tgl is ignoring our RING_TAIL updates, but more likely is that there is a missing update required for our semaphore waits around preemption. v2: And disable internal semaphore usage Signed-off-by:
-
