- 04 Jun, 2020 9 commits
-
-
Matt Roper authored
The pin mapping for the final two outputs varies according to which PCH is present on the platform: with TGP the pins are remapped into the TC range, whereas with CMP they stay in the traditional combo output range. Bspec: 49181 Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-9-matthew.d.roper@intel.com
-
Lucas De Marchi authored
RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of view, so all DDI/pipe/transcoder register use these indexes to refer to them. Combo phy and IO functions follow another namespace that we keep as "enum phy". The VBT in theory would use the DE point of view, but that does not happen in practice. Provide a table to convert the child devices to the "correct" port numbering we use. Now this is the output we get while reading the VBT: DDIA: [drm:intel_bios_port_aux_ch [i915]] using AUX A for port A (VBT) [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:275:DDI A] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:275:DDI A] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x1 for port A (VBT) DDIB: [drm:intel_bios_port_aux_ch [i915]] using AUX B for port B (platform default) [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:291:DDI B] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x2 for port B (VBT) DDI USBC1: [drm:intel_bios_port_aux_ch [i915]] using AUX D for port D (VBT) [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:295:DDI D] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:295:DDI D] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x3 for port D (VBT) DDI USBC2: [drm:intel_bios_port_aux_ch [i915]] using AUX E for port E (VBT) [drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:306:DDI E] [drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:306:DDI E] [drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x9 for port E (VBT) Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-7-matthew.d.roper@intel.com
-
Matt Roper authored
Although we properly captured RKL's three pipes in the device info structure, we forgot to make the corresponding update to the transcoder mask. Set this field so that our transcoder loops will operate properly. Fixes: 123f62de ("drm/i915/rkl: Add RKL platform info and PCI ids") Signed-off-by:
-
Chris Wilson authored
Sometimes an engine might need to keep forcewake active while it is busy submitting requests for a particular workaround. Track such nuisance with engine->fw_domain. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200604153145.21068-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Use the plain msec_to_jiffies() rather than the _timeout variant so we round down and do not add an extra jiffy to our interval. For example, with timeslicing we do not want to err on the longer side as any fairness depends on catching hogging contexts on the GPU. Bring on CFS. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200604135938.3975-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If the execbuf is interrupted after building the cmdparser pipeline, and before we commit to submitting the request to HW, we would attempt to clean up the cmdparser early. While we held active references to the vma being parsed and constructed, we did not hold an active reference for the buffer pool itself. The result was that an interrupted execbuf could still have run the cmdparser pipeline, but since the buffer pool was idle, its target vma could have been recycled. Note this problem only occurs if the cmdparser is running async due to pipelined waits on busy fences, and the execbuf is interrupted. Fixes: 686c7c35 ("drm/i915/gem: Asynchronous cmdparser") Fixes: 16e87459 ("drm/i915/gt: Move the batch buffer pool from the engine to the gt") Signed-off-by:
-
Clint Taylor authored
Set GS Timer to 224. Combine with Wa_1604555607 due to register FF_MODE2 not being able to be read. V2: Math issue fixed Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Caz Yokoyama <caz.yokoyama@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Acked-by:
-
Chris Wilson authored
Just to remove an obnoxious HAS_ENGINES(), and in the process make the code agnostic to the availabilty of any particular engine by making it exercise any and all such engines declared on the system. Signed-off-by:
-
Jani Nikula authored
The reset member in i915_params was previously changed to unsigned, but this failed to change the actual module parameter. Fixes: aae970d8 ("drm/i915: Mark i915.reset as unsigned") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602151126.25626-1-jani.nikula@intel.com
-
- 03 Jun, 2020 8 commits
-
-
Ville Syrjälä authored
Use max() instead of hand rolling it. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
The DP spec says: "When the combination of the requested pre-emphasis level and voltage swing exceeds the capability of a DPTX, the DPTX shall set the pre-emphasis level according to the request and use the highest voltage swing it can output with the given pre-emphasis level." and "When a DPTX reads a request beyond the limits of this Standard, the DPTX shall set the pre-emphasis level according to the request and set the highest voltage swing level it can output with the given pre-emphasis level. If a DPTX is requested for 9.5dB of pre-emphasis level (may be supported for a DPTX) and cannot support that level, it shall set the pre-emphasis level to the next highest level, 6dB." Ie. we should first validate the pre-emphasis, and then select the appropriate vswing for it. Signed-off-by:
-
Ville Syrjälä authored
Different platforms have different max vswing/preemph settings. Turn that into a pair vfuncs so we can decouple intel_dp.c and intel_ddi.c further. Signed-off-by:
-
Ville Syrjälä authored
According to the DP spec supporting vswing 1 + preemph 2 is mandatory. We don't have the hw settings for that though. In order to pretend to follow the DP spec let's just select vswing 0 + preemph 2 in this case (the DP spec says to use the requested preemph in preference to the vswing when the requested values aren't supported). Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
IBX supports vswing level 3 and pre-emphasis level 3. Don't limit it to level 2 for those. Signed-off-by:
-
Ville Syrjälä authored
cpt/ppt support pre-emphasis level 3. Let's actually declare support for it, instead of clamping things to level 2. Also tweak the if-ladder in intel_dp_voltage_max() to match intel_dp_pre_emphasis_max() to make it easier to compare them. Signed-off-by:
-
Chris Wilson authored
We infrequently use the direct i915 backpointer from the i915_request, so do we really need to waste the space in the struct for it? 8 bytes from the most frequently allocated struct vs an 3 bytes and pointer chasing in using rq->engine->i915? Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602220953.21178-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we injected an error (such as pretending the GuC firmware was broken), then suppress the error message as it is expected and our CI complains if it sees any *ERROR*. Signed-off-by:
-
- 02 Jun, 2020 9 commits
-
-
Chris Wilson authored
For reasons that be, the HW only allows usersace to read its own CTX_TIMESTAMP [context local HW runtime] on rcs. Make it available for all by adding it to the whitelists. v2: The change took effect from Cometlake. Signed-off-by:
-
Chris Wilson authored
Cometlake is a small refresh of Coffeelake, but since we have found out a difference in the plaforms, we need to identify them as separate platforms. Since we previously took Coffeelake/Cometlake as identical, update all IS_COFFEELAKE() to also include IS_COMETLAKE(). Signed-off-by:
-
Chris Wilson authored
As a timestamp will automatically update itself, it will not hold only contexts we write into it, and will change from the baseline value making us suspect that our writes are landing. As this confuses us and we would need more careful treatment to detect invalid stores into the timestamp, skip it when verifying the whitelists. Signed-off-by:
-
Vivek Kasireddy authored
If an error is encountered during the DSI initialization setup, the drm connector object also needs to be cleaned up along with the encoder. The error can happen due to a missing mode in the VBT or for other reasons. v2: Rephrase the commit message to make it more clear. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by:
-
Jani Nikula authored
Only support runtime changes through the debugfs. i915.verbose_state_checks remains an exception, and is not exposed via debugfs. This depends on IGT having been updated to use the debugfs for modifying the parameters. Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Jani Nikula authored
fake_lmem_start does not need to be mutable via module param sysfs. It's only used during driver probe. Fixes: 16292243 ("drm/i915/lmem: add the fake lmem region") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
The parameter only makes sense as a module parameter only. Fixes: c43c5a88 ("drm/i915/params: add i915 parameters to debugfs") Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Reviewed-by:
-
Chris Wilson authored
Use the central mechanism for recording and verifying that we restore the w/a for the older devices as well. Signed-off-by:
-
Chris Wilson authored
Pull the routines for writing CS packets out of intel_ring_submission into their own files. These are low level operations for building CS instructions, rather than the logic for filling the global ring buffer with requests, and we will want to reuse them outside of this context. Signed-off-by:
-
- 01 Jun, 2020 7 commits
-
-
Chris Wilson authored
Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f3975 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by:
-
José Roberto de Souza authored
Small updates in dkl_de_emphasis_control field. BSpec: 49292 Signed-off-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200529232757.37832-1-jose.souza@intel.com
-
Chris Wilson authored
Ever noticed that our interrupt handlers are where we spend most of our time on a busy system? In part this is unavoidable as each interrupt requires to poll and reset several registers, but we can try and do so as efficiently as possible. Function old new delta ilk_irq_handler 2317 2156 -161 v2: Restore the irqreturn_t ret Function old new delta ilk_irq_handler.cold 63 72 +9 ilk_irq_handler 2221 2080 -141 A slight improvement in the baseline overnight as well! Signed-off-by:
-
Ville Syrjälä authored
While the current locking/serialization of the global state suffices for protecting the obj->state access and the actual hardware reprogramming, we do have a problem with accessing the old/new states during nonblocking commits. The state computation and swap will be protected by the crtc locks, but the commit_tails can finish out of order, thus also causing the atomic states to be cleaned up out of order. This would mean the commit that started first but finished last has had its new state freed as the no-longer-needed old state by the other commit. To fix this let's just refcount the states. obj->state amounts to one reference, and the intel_atomic_state holds extra references to both its new and old global obj states. Fixes: 0ef1905e ("drm/i915: Introduce better global state handling") Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Chris Wilson authored
Our forcewake utilisation is split into categories: automatic and manual. Around bare register reads, we look up the right forcewake domain and automatically acquire and release [upon a timer] the forcewake domain. For other access, where we know we require the forcewake across a group of register reads, we manually acquire the forcewake domain and release it at the end. Again, this currently arms the domain timer for a later release. However, looking at some energy utilisation profiles, we have tried to avoid using forcewake [and rely on the natural wake up to post register updates] due to that even keep the fw active for a brief period contributes to a significant power draw [i.e. when the gpu is sleeping with rc6 at high clocks]. But as it turns out, not posting the writes immediately also has unintended consequences, such as not reducing the clocks and so conserving power while busy. As a compromise, let us only arm the domain timer for automatic forcewake usage around bare register access, but immediately release the forcewake when manually acquired by intel_uncore_forcewake_get/_put. The corollary to this is that we may instead have to take forcewake more often, and so incur a latency penalty in doing so. For Sandybridge this was significant, and even on the latest machines, taking forcewake at interrupt frequency is a huge impact. [So we don't do that anymore! Hopefully, this will spare us from still needing the mitigation of the timer for steady state execution.] Signed-off-by:
-
Chris Wilson authored
If we fail during engine setup, we may leave some engines not yet setup. During the error cleanup, we have to be careful not to try and use the uninitialise engines before discarding them. [ 16.136152] RIP: 0010:__flush_work+0x198/0x1b0 [ 16.136168] Code: ff ff 8b 0b 48 8b 53 08 83 e1 08 48 0f ba 2b 03 80 c9 f0 e9 63 ff ff ff 0f 0b 48 83 c4 48 44 89 f0 5b 5d 41 5c 41 5d 41 5e c3 <0f> 0b 45 31 f6 e9 62 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f [ 16.136186] RSP: 0018:ffffc900003bb928 EFLAGS: 00010246 [ 16.136201] RAX: 0000000000000000 RBX: ffff88844f392168 RCX: 0000000000000000 [ 16.136216] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88844f392168 [ 16.136231] RBP: ffff88844f392130 R08: 0000000000000000 R09: 0000000000000001 [ 16.136246] R10: ffff888441e31e40 R11: ffff88845e329c70 R12: ffff88844f796988 [ 16.136261] R13: ffff888441e4fb80 R14: 0000000000000001 R15: ffff88844f790000 [ 16.136388] FS: 00007fecbd208880(0000) GS:ffff88845e380000(0000) knlGS:0000000000000000 [ 16.136405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.136420] CR2: 00007ff3ce748f90 CR3: 0000000457a6a001 CR4: 00000000000606e0 [ 16.136437] Call Trace: [ 16.136456] ? try_to_del_timer_sync+0x3a/0x50 [ 16.136529] intel_wakeref_wait_for_idle+0x87/0xb0 [i915] [ 16.136606] ? intel_engines_release+0x68/0xc0 [i915] [ 16.136680] intel_engines_release+0x49/0xc0 [i915] [ 16.136757] intel_gt_init+0x2f4/0x5e0 [i915] Signed-off-by:
-
Kishore Kadiyala authored
Currently the plane property doesn't have support for YCBCR_BT2020, which enables the corresponding color conversion mode on plane CSC. Enabling the plane property for the planes for GLK & ICL+ platforms. Also as per spec, update the Plane Color CSC from YUV601_TO_RGB709 to YUV601_TO_RGB601. V2: Enabling support for YCBCT_BT2020 for HDR planes on platforms GLK & ICL V3: Refined the condition check to handle GLK & ICL+ HDR planes Also added BT2020 handling in glk_plane_color_ctl. V4: Combine If-else into single If V5: Drop the checking for HDR planes and enable YCBCR_BT2020 for platforms GLK & ICL+. V6: As per Spec, update PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709 to PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 as per Ville's feedback. V7: Rebased Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Kishore Kadiyala <kishore.kadiyala@intel.com> Signed-off-by:
-
- 29 May, 2020 6 commits
-
-
Chris Wilson authored
Name the object classes and their offspring for easier lockdep debugging. Signed-off-by:
-
Chris Wilson authored
If we declare that an object type is shrinkable (any that we can reclaim to recover system pages), make sure we taint the object mutex so that lockdep expects us to use it within fs_reclaim. lockdep will then complain the first time we try to allocate while holding the plain mutex, as doing so invites potential recursion. Signed-off-by:
-
Chris Wilson authored
With the advent of preempt-to-busy, a request may still be on the GPU as we unwind. And in the case of a unpreemptible [due to HW] request, that request will remain indefinitely on the GPU even though we have returned it back to our submission queue, and cleared the active bit. We only run the execution callbacks on transferring the request from our submission queue to the execution queue, but if this is a bonded request that the HW is waiting for, we will not submit it (as we wait for a fresh execution) even though it is still being executed. As we know that there are always preemption points between requests, we know that only the currently executing request may be still active even though we have cleared the flag. However, we do not precisely know which request is in ELSP[0] due to a delay in processing events, and furthermore we only store the last request in a context in our state tracker. Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Testcase: igt/gem_exec_balancer/bonded-dual Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200529143926.3245-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Let's assert that we only call the execute callbacks on making the request active, and that we do not execute the request without calling the callbacks. Signed-off-by:
-
Ville Syrjälä authored
There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag anymore. Just make it a boolean. v2: Deal with sanitize_watermarks() CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Replace the use of mode->private_flags with a truly private bitmaks in our own crtc state. We also need a copy in the crtc itself so the vblank code can get at it. We already have scanline_offset in there for a similar reason, as well as the vblank->hwmode which is assigned via drm_calc_timestamping_constants(). Fortunately we now have a nice place for doing the crtc_state->crtc copy in intel_crtc_update_active_timings() which gets called both for modesets and init/resume readout. The one slightly iffy spot is the INHERITED flag which we want to preserve until userspace/fb_helper does the first proper commit after actually calling .detecti() on the connectors. Otherwise we don't have the full sink capabilities (audio,infoframes,etc.) when .compute_config() gets called and thus we will fail to enable those features when the first userspace commit happens. The only internal commit we do prior to that should be from intel_initial_commit() and there we can simply preserve the INHERITED flag from the readout. v2: Deal with INHERITED in sanitize_watermarks() as well CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
-
- 28 May, 2020 1 commit
-
-
Chris Wilson authored
We may choose to only submit ELSP[0], even though we have sufficient requests to fill the whole ELSP. Normally, we only start timeslicing if we fill more than one port, but in this case we need to start timeslicing for the queue that we choose not to submit. Signed-off-by:
-
