- 19 Jul, 2019 3 commits
-
-
Tvrtko Ursulin authored
fls returns bit positions starting from one for the lsb and the MCR register expects zero based (sub)slice addressing. Incorrent MCR programming can have the effect of directing MMIO reads of registers in the 0xb100-0xb3ff range to invalid subslice returning zeroes instead of actual content. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 1e40d4ae ("drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads") Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190717180624.20354-2-tvrtko.ursulin@linux.intel.com
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/i915/display/intel_sprite.c: In function 'g4x_sprite_check_scaling': drivers/gpu/drm/i915/display/intel_sprite.c:1494:13: warning: variable 'src_y' set but not used [-Wunused-but-set-variable] Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719024100.64738-1-yuehaibing@huawei.com
-
Chris Wilson authored
As we unwind the requests for a preemption event, we return a virtual request back to its original virtual engine (so that it is available for execution on any of its siblings). In the process, this means that its breadcrumb should no longer be associated with the original physical engine, and so we are forced to decouple it. Previously, as the request could not complete without our awareness, we would move it to the next real engine without any danger. However, preempt-to-busy allowed for requests to continue on the HW and complete in the background as we unwound, which meant that we could end up retiring the request before fixing up the breadcrumb link. [51679.517943] INFO: trying to register non-static key. [51679.517956] the code is fine but needs lockdep annotation. [51679.517960] turning off the locking correctness validator. [51679.517966] CPU: 0 PID: 3270 Comm: kworker/u8:0 Tainted: G U 5.2.0+ #717 [51679.517971] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [51679.518012] Workqueue: i915 retire_work_handler [i915] [51679.518017] Call Trace: [51679.518026] dump_stack+0x67/0x90 [51679.518031] register_lock_class+0x52c/0x540 [51679.518038] ? find_held_lock+0x2d/0x90 [51679.518042] __lock_acquire+0x68/0x1800 [51679.518047] ? find_held_lock+0x2d/0x90 [51679.518073] ? __i915_sw_fence_complete+0xff/0x1c0 [i915] [51679.518079] lock_acquire+0x90/0x170 [51679.518105] ? i915_request_cancel_breadcrumb+0x29/0x160 [i915] [51679.518112] _raw_spin_lock+0x27/0x40 [51679.518138] ? i915_request_cancel_breadcrumb+0x29/0x160 [i915] [51679.518165] i915_request_cancel_breadcrumb+0x29/0x160 [i915] [51679.518199] i915_request_retire+0x43f/0x530 [i915] [51679.518232] retire_requests+0x4d/0x60 [i915] [51679.518263] i915_retire_requests+0xdf/0x1f0 [i915] [51679.518294] retire_work_handler+0x4c/0x60 [i915] [51679.518301] process_one_work+0x22c/0x5c0 [51679.518307] worker_thread+0x37/0x390 [51679.518311] ? process_one_work+0x5c0/0x5c0 [51679.518316] kthread+0x116/0x130 [51679.518320] ? kthread_create_on_node+0x40/0x40 [51679.518325] ret_from_fork+0x24/0x30 [51679.520177] ------------[ cut here ]------------ [51679.520189] list_del corruption, ffff88883675e2f0->next is LIST_POISON1 (dead000000000100) Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
- 18 Jul, 2019 6 commits
-
-
Dhinakaran Pandiyan authored
A single 32-bit PSR2 training pattern field follows the sixteen element array of PSR table entries in the VBT spec. But, we incorrectly define this PSR2 field for each of the PSR table entries. As a result, the PSR1 training pattern duration for any panel_type != 0 will be parsed incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb version >= 226 will also be wrong. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: stable@vger.kernel.org Cc: stable@vger.kernel.org #v5.2 Fixes: 88a0d960 ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by:
François Guerraz <kubrick@fgv6.net> Signed-off-by:
-
Chris Wilson authored
As recently disovered by forcing big-core (!llc) machines to use the GTT paths, we need our full GTT write flush before manipulating the GTT PTE or else the writes may be directed to the wrong page. Signed-off-by:
-
Chris Wilson authored
Inside pread, we only ever read from the GTT so the serialising wmb() instructions around the GGTT PTE updates are pointless. Signed-off-by:
-
Ville Syrjälä authored
On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: stable@vger.kernel.org Tested-by:
Stefan Gottwald <gottwald@igel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149Signed-off-by:
-
Vivek Kasireddy authored
Although, DPLL4 enable and disable is associated with MGPLL1_ENABLE register, we can use ICL_DPLL_CFGCR0/CR1 macros to access this dpll's CR0 and CR1 registers by passing an id of 4 to these macros. Reported-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Reduce the clutter a bit by introducing gen8_de_pipe_fault_mask(). Signed-off-by:
-
- 17 Jul, 2019 5 commits
-
-
Michel Thierry authored
Reuse Gen11 stolen memory changes since Tiger Lake uses the same BSM register (and format). Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190712210238.5622-1-lucas.demarchi@intel.com
-
Chris Wilson authored
Push the engine stop into the back reset_prepare (where it already was!) This allows us to avoid dangerously setting the RING registers to 0 for logical contexts. If we clear the register on a live context, those invalid register values are recorded in the logical context state and replayed (with hilarious results). Signed-off-by:
-
Chris Wilson authored
By stopping the rings, we may trigger an arbitration point resulting in a premature context-switch (i.e. a completion event before the request is actually complete). This clears the active context before the reset, but we must remember to rewind the incomplete context for replay upon resume. Fixes: 1863e302 ("drm/i915/execlists: Always reset the context's RING registers") Signed-off-by:
-
Tvrtko Ursulin authored
Commit f774f096 ("drm/i915/guc: Turn on GuC/HuC auto mode") changed the default from 0 to -1 but forgot to update the description. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Chris Wilson authored
Avoid a global idle barrier by reconfiguring each context by rewriting them with MI_STORE_DWORD from the kernel context. v2: We only need to determine the desired register values once, they are the same for all contexts. v3: Don't remove the kernel context from the list of known GEM contexts; the world is not ready for that yet. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190716213443.9874-1-chris@chris-wilson.co.uk
-
- 16 Jul, 2019 4 commits
-
-
Chris Wilson authored
Apply the new radix shift helpers to extract the multi-level indices cleanly when inserting pte into the gtt tree. Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712112725.2892-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
Refactor the separate allocation routines into a single recursive function. Signed-off-by:
-
Chris Wilson authored
Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across preemption, but mediated gvt does not fully support semaphores. v2: Fiddle around with the flags and settle on using has-semaphores for the core bits so that we retain the ability to preempt our own semaphores. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190709091233.8573-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We cannot let the request be retired and freed while we are trying to dump it during error capture. It is not sufficient just to grab a reference to the request, as during retirement we may free the ring which we are also dumping. So take the engine lock to prevent retiring and freeing of the request. Reported-by:
Alex Shumsky <alexthreed@gmail.com> Fixes: 83c31783 ("drm/i915: Dump the ringbuffer of the active request for debugging") Signed-off-by:
-
- 15 Jul, 2019 4 commits
-
-
José Roberto de Souza authored
Right now we are aware of two cases that needs another hotplug retry: - Unpowered type-c dongles - HDMI slow unplug Both have a complete explanation in the code to schedule another run of the hotplug handler. It could have more checks to just trigger the retry in those two specific cases but why would sink signal a long pulse if there is no change? Also the drawback of running the hotplug handler again is really low and that could fix another cases that we are not aware. Also retrying for old DP ports(non-DDI) to make it consistent and not cause CI failures if those systems are connected to chamelium boards that will be used to simulate the issues reported in here. v2: Also retrying for old DP ports(non-DDI)(Imre) v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep it consistent(Rodrigo) Tested-by:
Timo Aaltonen <tjaalton@ubuntu.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Imre Deak authored
There is some scenarios that we are aware that sink probe can fail, so lets add the infrastructure to let hotplug() hook to request another probe after some time. v2: Handle shared HPD pins (Imre) v3: Rebased v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep it consistent(Rodrigo) v5: Making the working queue used explicit through all the callers to hotplug_work (Ville) Tested-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Matt Roper authored
Now that we distinguish between phy and port(ddi), mcc_port_to_ddc_pin should use the phy, not the DDI, for determining DDC pins. We're only converting the MCC function at the moment since EHL is the only platform that has configurations where port!=phy. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712221641.21031-1-matthew.d.roper@intel.comReviewed-by:
-
Chris Wilson authored
GVT forces single port submission of individual requests. We do not enjoy the context amalgamation that the test depends upon for setting up the test (where port 0 has a large number of requests with a priority change somewhere in the middle). Under single request submission of gvt it is quite able for the preemption event to occur while another context is active and so there be a real need to act upon that preemption. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111108Signed-off-by:
-
- 13 Jul, 2019 11 commits
-
-
Daniele Ceraolo Spurio authored
Get rid of them to avoid more users being added while the guc code transitions to use gt more than i915. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by:
-
Daniele Ceraolo Spurio authored
We can get rid of a few more guc_to_i915 and start compartmentalizing interrupt management a bit more. We should be able to move more code in the future once the gt_pm code is also moved across to gt. Signed-off-by:
-
Daniele Ceraolo Spurio authored
With our HW interface logic moving from i915 to gt and with GuC and HuC being part of the gt HW, it makes sense to use the intel_gt structure instead of i915 as our reference object in GuC/HuC paths. Signed-off-by:
-
Daniele Ceraolo Spurio authored
All the intel_uc_* can now be moved to work on the intel_uc structure for better encapsulation of uc-related actions. Note: I've introduced uc_to_gt instead of uc_to_i915 because the aim is to move everything to be gt-focused in the medium term, so we would've had to replace it soon anyway. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Being part of the GT HW, it make sense to keep the guc/huc structures inside the GT structure. To help with the encapsulation work done by the following patches, both structures are placed inside a new intel_uc container. Although this results in code with ugly nested dereferences (i915->gt.uc.guc...), it saves us the extra work required in moving the structures twice (i915 -> gt -> uc). The following patches will reduce the number of places where we try to access the guc/huc structures directly from i915 and reduce the ugliness. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Both microcontrollers are part of the GT HW and are closely related to GT operations. To keep all the files cleanly together, they've been placed in their own subdir inside the gt/ folder Signed-off-by:
-
Daniele Ceraolo Spurio authored
The 16-bit guc irq vector is unchanged across gens, the only thing that moved is its position (from the upper 16 bits of the PM regs to its own register). Instead of duplicating all defines and functions to handle the 2 different positions, we can work on the vector and shift it as appropriate. While at it, update the handler to work on intel_guc. Signed-off-by:
-
Daniele Ceraolo Spurio authored
No functional change, just moving the guc_to_i915 from the caller into the irq function. This will help with the upcoming move of guc under intel_gt. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Instead of always checking in the device config is GuC and HuC are supported or not, we can save the state in the uc_fw structure and avoid going through i915 every time from the low-level uc management code. while at it FIRMWARE_NONE has been renamed to better indicate that we haven't started the fetch/load yet, but we might have already selected a blob. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The "misc" terminology doesn't clearly explain what we intend to cover in this phase. The only thing we used ot do in there apart from FW fetch was initializing the log workqueue, with the latter being required only in the very rare case where we enable the log relay. As we no longer create our own workqueue, piggybacking on the system_highpri_wq instead, we can rename the function to clarify that they only fetch/release the blobs. v2: only create log wq when needed (Michal), reword commit msg accordingly v3: after rebase the wq is gone, reword commit msg accordingly Signed-off-by:
-
Chris Wilson authored
We only employ a single task for log capture, and created a workqueue for the purpose of ensuring we had a high priority queue for low latency. We can simply use the system_highpri_wq and avoid the complication with creating our own admist the maze of mutexes. (Currently we create the wq early before we even know we need it in order to avoid trying to create it on demand while we hold the logging mutex.) Signed-off-by:
-
- 12 Jul, 2019 7 commits
-
-
Chris Wilson authored
Having taken the first step in encapsulating the functionality by moving the related files under gt/, the next step is to start encapsulating by passing around the relevant structs rather than the global drm_i915_private. In this step, we pass intel_gt to intel_reset.c Signed-off-by:
-
Lucas De Marchi authored
Tiger Lake has modular FIA bit indicating if we are using it, so add to the device info. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712055706.12143-3-lucas.demarchi@intel.com
-
Anusha Srivatsa authored
Some platforms may have Modular FIA. If Modular FIA is used in the SOC, then Display Driver will access the additional instances of FIA based on pre-assigned offset in GTTMADDR space. Each Modular FIA instance has its own IOSF Sideband Port ID and it houses only 2 Type-C Port. In SOC that has more than two Type-C Ports, there are multiple instances of Modular FIA. Gunit will need to use different destination ID when it access different pair of Type-C Port. The DFLEXDPSP register has Modular FIA bit starting on Tiger Lake. If Modular FIA is used in the SOC, this register bit exists in all the instances of Modular FIA. IOM FW is required to program only the MF bit in first FIA instance that houses the Type-C Port 0 and Port 1, for Display Driver to read from. v2 (Lucas): - Move all accesses to FIA to be contained in intel_tc.c, along with display_fia that is now called tc_phy_fia - Save the fia instance number on intel_digital_port, so we don't have to query if modular FIA is used on every access v3 (Lucas): Make function static v4 (Lucas): Move enum phy_fia to the header and use it in intel_digital_port (suggested by Ville) v5 (Lucas): Add comment about the mapping between FIA and TC port (suggested by Stuart) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Chris Wilson authored
With an explicit level, we can refactor the separate clear functions as a simple recursive function. The additional knowledge of the level allows us to spot when we can free an entire subtree at once. Signed-off-by:
-
Chris Wilson authored
With an explicit level, we can refactor the separate cleanup functions as a simple recursive function. We take the opportunity to pass down the size of each level so that we can deal with the different sizes of top-level and avoid over allocating for 32/36-bit vm. Signed-off-by:
-
Chris Wilson authored
intel_atomic_commit() is not for use internally, but only as an entry point from the core drm atomic helper (drm_atomic_commit). Squelches the warning for: drivers/gpu/drm/i915/display/intel_display.c:14148: warning: Function parameter or member '_state' not described in 'intel_atomic_commit' drivers/gpu/drm/i915/display/intel_display.c:14148: warning: Excess function parameter 'state' description in 'intel_atomic_commit' Signed-off-by:
-
Ville Syrjälä authored
CH7511 doesn't update SINK_COUNT properly so in order to detect the device as connected we have to ignore SINK_COUNT. In order to have access to the quirk list early enough we must move the drm_dp_read_desc() call to happen earlier. We can also skip re-reading this on eDP since we know it won't change. Cc: David S. <david@majinbuu.com> Cc: Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Tested-by:
Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105406Signed-off-by:
-
