summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-12-12drm/i915: merge gen checks to use rangeLucas De Marchi
Instead of using IS_GEN() for consecutive gen checks, let's pass the range to IS_GEN_RANGE(). By code inspection these were the ranges deemed necessary for spatch: @@ expression e; @@ ( - IS_GEN(e, 3) || IS_GEN(e, 2) + IS_GEN_RANGE(e, 2, 3) | - IS_GEN(e, 3) || IS_GEN(e, 4) + IS_GEN_RANGE(e, 3, 4) | - IS_GEN(e, 5) || IS_GEN(e, 6) + IS_GEN_RANGE(e, 5, 6) | - IS_GEN(e, 6) || IS_GEN(e, 7) + IS_GEN_RANGE(e, 6, 7) | - IS_GEN(e, 7) || IS_GEN(e, 8) + IS_GEN_RANGE(e, 7, 8) | - IS_GEN(e, 8) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 8, 9) | - IS_GEN(e, 10) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 9, 10) | - IS_GEN(e, 9) || IS_GEN(e, 10) + IS_GEN_RANGE(e, 9, 10) ) After conversion, checking we don't have any missing IS_GEN_RANGE() || IS_GEN() was also done. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-3-lucas.demarchi@intel.com
2018-12-12drm/i915: replace IS_GEN<N> with IS_GEN(..., N)Lucas De Marchi
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-12drm/i915: Rename IS_GEN to IS_GEN_RANGELucas De Marchi
RANGE makes it longer, but clearer. We are also going to add a macro to check an individual gen, so add the _RANGE prefix here. Diff generated with: sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i v2: use IS_GEN rather than GT_GEN Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-1-lucas.demarchi@intel.com
2018-12-12drm/i915: Don't forget to reset blocks when testing lower wm levelsMatt Roper
During DDB allocation, we try to distribute enough blocks for each plane to hit the highest watermark level; if that fails, we retry each lower level (which should require fewer blocks) until we find one that's possible (or until the whole commit is rejected as impossible). We need to reset our running block count when trying each lower level, otherwise all lower levels will fail as well. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation algorithm (v5)") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212191720.3706-1-matthew.d.roper@intel.com
2018-12-11drm/i915: DFSM pipe disable is valid from gen9 onwards (v2)Bob Paauwe
It's not just GEN9 platforms that allow for pipes to be disabled via the DFSM register, but all later platforms as well. v2: drop pointless parentheses (Ville) Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181211192545.140081-1-bob.j.paauwe@intel.com
2018-12-11drm/i915: Switch to level-based DDB allocation algorithm (v5)Matt Roper
The DDB allocation algorithm currently used by the driver grants each plane a very small minimum allocation of DDB blocks and then divies up all of the remaining blocks based on the percentage of the total data rate that the plane makes up. It turns out that this proportional allocation approach is overly-generous with the larger planes and can leave very small planes wthout a big enough allocation to even hit their level 0 watermark requirements (especially on APL, which has a smaller DDB in general than other gen9 platforms). Or there can be situations where the smallest planes hit a lower watermark level than they should have been able to hit with a more equitable division of DDB blocks, thus limiting the overall system sleep state that can be achieved. The bspec now describes an alternate algorithm that can be used to overcome these types of issues. With the new algorithm, we calculate all plane watermark values for all wm levels first, then go back and partition a pipe's DDB space second. The DDB allocation will calculate what the highest watermark level that can be achieved on *all* active planes, and then grant the blocks necessary to hit that level to each plane. Any remaining blocks are then divided up proportionally according to data rate, similar to the old algorithm. There was a previous attempt to implement this algorithm a couple years ago in bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but some regressions were reported, the patch was reverted, and nobody ever got around to figuring out exactly where the bug was in that version. Our watermark code has evolved significantly in the meantime, but we're still getting bug reports caused by the unfair proportional algorithm, so let's give this another shot. v2: - Make sure cursor allocation stays constant and fixed at the end of the pipe allocation. - Fix some watermark level iterators that weren't handling the max level. v3: - Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min to calculate the extra blocks for each plane. (Ville) - Replace a while() loop with a for() loop to be more consistent with surrounding code. (Ville) - Clean unattainable watermark levels with memset rather than directly clearing the member fields. Also do the same for the transition watermark values if they can't be achieved. (Ville) - Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since the results are no longer needed or used. (Ville) - Drop skl_latency[0] != 0 sanity check; both watermark methods already account for an invalid 0 latency by returning FP_16_16_MAX. (Ville) v4: - Break DDB allocation loop when total_data_rate=0 rather than alloc_size=0. If total_data_rate has dropped to 0, all remaining planes are disabled, which isn't true for alloc_size (we might just have not had any remaining blocks to hand out). Plus total_data_rate=0 is the case we need to avoid to a prevent a div-by-0. (Ville) - s/DIV_ROUND_UP/DIV64_U64_ROUND_UP/ to prevent 32-bit breakage (Ville) v5: - Don't forget to move 'start' pointer forward for UV surface when setting plane DDB boundaries. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-2-matthew.d.roper@intel.com
2018-12-11drm/i915: Don't use DDB allocation when choosing gen9 watermark methodMatt Roper
The bspec gives an if/else chain for choosing whether to use "method 1" or "method 2" for calculating the watermark "Selected Result Blocks" value for a plane. One of the branches of the if chain is: "Else If ('plane buffer allocation' is known and (plane buffer allocation / plane blocks per line) >=1)" Since our driver currently calculates DDB allocations first and the actual watermark values second, the plane buffer allocation is known at this point in our code and we include this test in our driver's logic. However we plan to soon move to a "watermarks first, ddb allocation second" sequence where we won't know the DDB allocation at this point. Let's drop this arm of the if/else statement (effectively considering the DDB allocation unknown) as an independent patch so that any regressions can be more accurately bisected to either the different watermark value (in this patch) or the new DDB allocation (in the next patch). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181211173107.11068-1-matthew.d.roper@intel.com
2018-12-11drm/i915/hdmi: SCDC Scrambling enable without CTS modeClint Taylor
Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests HF1-12 and HF1-13 to fail. V2: Removed "Source Shall" entries to a new patch V3: Rebase to drm-tip Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107895 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107896 Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1544482374-26507-1-git-send-email-clinton.a.taylor@intel.com
2018-12-10drm/i915: Use intel_ types more consistently for color management code (v2)Matt Roper
Try to be more consistent about intel_* types rather than drm_* types for lower-level driver functions. While we're at it, let's also be more consistent with state variable naming (half of the platforms use the name 'state' whereas the other half used 'crtc_state'). While we're touching these variables, let's also be more consistent about always naming the intel_crtc_state's "crtc_state" rather than "state" so that different platform types aren't using different naming conventions. v2: - s/state/crtc_state/ for consistency between platform types (Ville) - Drop the crtc parameter to intel_color_check(); we can just pull that out of the state object. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181210215415.19854-2-matthew.d.roper@intel.com
2018-12-10drm/i915: Use intel_ types more consistently for watermark code (v2)Matt Roper
Try to be more consistent about intel_* types rather than drm_* types for lower-level driver functions. v2: - Also drop the intel_crtc parameter from compute_intermediate_wm() since we can just extract it from the crtc_state parameter. (Ville) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181210215415.19854-1-matthew.d.roper@intel.com
2018-12-07drm/i915: Remove dead update_wm_pre assignment from SKL wm codeVille Syrjälä
SKL+ do not use crtc_state->update_wm_pre, so there is absolutely no point it setting it. crtc_state->update_wm_pre only exists as a temporary hack for pre-g4x platforms until we redo their watermarks to be be atomic. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181113172330.26069-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-12-07drm/i915: Remove bogus FIXME from SKL wm computationVille Syrjälä
We do return an error when the watermark calculation fails, so the FIXME claiming otherwise is outdated. Remove it. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181113172330.26069-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-12-07drm/i915: Use explicit old crtc state in skl_compute_wm()Ville Syrjälä
skl_compute_wm() wants to compare the old and new watermarks. Currently it gets at the old watermarks via crtc->state, which is confusing since it can point at either the old or the new state depending on where in the sequence we are. In this case it is correct since we have not yet swapped the states, but let's make it super clear what this is doing by using the explicit old state. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181113172330.26069-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-12-07drm/i915: Flush GPU relocs harder for gen3Chris Wilson
Adding an extra MI_STORE_DWORD_IMM to the gpu relocation path for gen3 was good, but still not good enough. To survive 24+ hours under test we needed to perform not one, not two but three extra store-dw. Doing so for each GPU relocation was a little unsightly and since we need to worry about userspace hitting the same issues, we should apply the dummy store-dw into the EMIT_FLUSH. Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing") References: 7fa28e146994 ("drm/i915: Write GPU relocs harder with gen3") Testcase: igt/gem_tiled_fence_blits # blb/pnv 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/20181207134037.11848-1-chris@chris-wilson.co.uk
2018-12-07drm/i915: Skip the ERR_PTR error stateChris Wilson
Although commit fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") applied cleanly after a 24 month hiatus, the code had moved on with new methods for peeking and fetching the captured gpu info. Make sure we catch all uses of the stashed error state and avoid dereferencing the error pointer. v2: Move error pointer determination into i915_gpu_capture_state v3: Restore early check to avoid capturing and then throwing away subsequent GPU error states. Fixes: fb6f0b64e455 ("drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207110554.19897-1-chris@chris-wilson.co.uk
2018-12-07drm/i915: Pipeline PDP updates for BraswellChris Wilson
Currently we face a severe problem on Braswell that manifests as invalid ppGTT accesses. The code tries to maintain the PDP (page directory pointers) inside the context in two ways, direct write into the context and a pipelined LRI update. The direct write into the context is fundamentally racy as it is unserialised with any access (read or write) the GPU is doing. By asserting that Braswell is not used with vGPU (currently an unsupported platform) we can eliminate the dangerous direct write into the context image and solely use the pipelined update. However, the LRI of the PDP fouls up the GPU, causing it to freeze and take out the machine with "forcewake ack timeouts". This seems possible to workaround by preventing the GPU from sleeping (via means of disabling the power-state management interface, i.e. forcing each ring to remain awake) around the update. Equally, it seems an EMIT_INVALIDATE before the LRI is sufficient to prevent the forcewake errors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656 References: https://bugs.freedesktop.org/show_bug.cgi?id=108714 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207090213.14352-3-chris@chris-wilson.co.uk
2018-12-07drm/i915/ringbuffer: EMIT_INVALIDATE after switch contextChris Wilson
The recommend procedure was to switch contexts (and mm) then invalidate the TLBs. Make it so. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207090213.14352-2-chris@chris-wilson.co.uk
2018-12-07drm/i915: Push EMIT_INVALIDATE at request start to backendsChris Wilson
Move the common engine->emit_flush(EMIT_INVALIDATE) back to the backends (where it was once previously) as we seek to specialise it in future patches. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207090213.14352-1-chris@chris-wilson.co.uk
2018-12-07drm/i915/icl: Forcibly evict stale csb entriesMika Kuoppala
Gen11 fails to deliver wrt global observation point on tail/entry updates and we sometimes see old entry. Use clflush to forcibly evict our possibly stale copy of the cacheline in hopes that we get fresh one from gpu. Obviously there is something amiss in the coherency protocol so this can be consired as a workaround until real cause is found. The working hardware will do the evict without our cue anyways, so the cost in there should be ameliorated by that fact. v2: for next pass, s/flush/evict, add reset (Chris) References: https://bugzilla.freedesktop.org/show_bug.cgi?id=108315 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181205134612.24822-1-mika.kuoppala@linux.intel.com
2018-12-06drm/i915/execlists: Apply a full mb before execution for BraswellChris Wilson
Braswell is really picky about having our writes posted to memory before we execute or else the GPU may see stale values. A wmb() is insufficient as it only ensures the writes are visible to other cores, we need a full mb() to ensure the writes are in memory and visible to the GPU. The most frequent failure in flushing before execution is that we see stale PTE values and execute the wrong pages. References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into context image vs execution") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181206084431.9805-3-chris@chris-wilson.co.uk
2018-12-06drm/i915/execlists: Move RCS mmio workaround to new common wa_listChris Wilson
We can move the remaining RCS workarounds applied to only gen8 to the engine->wa_list, and then reduce all engine->init_hw callbacks to common code. The benefit of using the new wa_list is that we verify that the registers are indeed restored and keep their magic values. v2: INSTPM_FORCE_ORDERING is already part of gen8_ctx_workarounds, and as confirmed by the mmio verification is a part of the context image! v3: MI_MODE is already part of gen8_ctx_workarounds... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181206180713.6827-2-chris@chris-wilson.co.uk
2018-12-06drm/i915/selftests: verify_gt_engine_wa() needs rpm wakerefChris Wilson
The mmio readback for verify_gt_engine_wa() also needs a runtime-pm wakeref, so effectively do the entirety of both engine workarounds tests. As such simplify the rpm behaviour here by acquiring the wakeref for the whole of each subtest. It would be still useful to later verify the registers retain their magic values across rpm suspend/resume. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181206180713.6827-1-chris@chris-wilson.co.uk
2018-12-06drm/i915: Increase timeout for Encrypt status changeRamalingam C
At enable/disable of the HDCP encryption, for encryption status change we need minimum one frame duration. And we might program this bit any point(start/End) in the previous frame. With 20mSec, observed the timeout for change in encryption status. Since this is not time critical operation and we need to hold on until the status is changed, fixing the timeout to 50mSec. (Based on trial and error method!) v2: %s/TIME_FOR_ENCRYPT_STATUS_CHANGE/ENCRYPT_STATUS_CHANGE_TIMEOUT_MS [Sean Paul] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-5-git-send-email-ramalingam.c@intel.com
2018-12-06drm/i915: debug log for REPLY_ACK missingRamalingam C
Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing for aksv write. This helps to locate the possible non responding DP HDCP sinks. v2: Rewritten for readability [Sean Paul] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-4-git-send-email-ramalingam.c@intel.com
2018-12-06drm/i915: Fix platform coverage for HDCP1.4Ramalingam C
HDCP1.4 is enabled and validated only on GEN9+ platforms. v2: Removed the unnecessary parens [Ville] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-3-git-send-email-ramalingam.c@intel.com
2018-12-06drm/i915: Fix GEN9 HDCP1.4 key load processRamalingam C
HDCP1.4 key load process varies between Intel platform to platform. For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using the GT Driver Mailbox interface. So all GEN9_BC platforms will use the GT Driver Mailbox interface for HDCP1.4 key load. v2: Using the IS_GEN9_BC for filtering the platforms [Ville] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1544010283-20223-2-git-send-email-ramalingam.c@intel.com
2018-12-05drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking areaJosé Roberto de Souza
GLK and CNL+ supports a bigger FBC tracking area. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181205004823.30823-1-jose.souza@intel.com
2018-12-05drm: Fix documentation generation for DP_DPCD_QUIRK_NO_PSRJosé Roberto de Souza
The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this warning when generating kernel documentation. ./include/drm/drm_dp_helper.h:1374: warning: Incorrect use of kernel-doc format: * @DP_DPCD_QUIRK_NO_PSR Fixes: 7c5c641a930e (drm/i915: Disable PSR in Apple panels) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181205184850.13218-1-jose.souza@intel.com
2018-12-05drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENTMatt Atwood
According to DP spec (2.9.3.1 of DP 1.4) if EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD 02200h through 0220Fh shall contain the DPRX's true capability. These values will match 00000h through 0000Fh, except for DPCD_REV, MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT. Read from DPCD once for all 3 values as this is an expensive operation. Spec mentions that all of address space 02200h through 0220Fh should contain the right information however currently only 3 values can differ. There is no address space in the intel_dp->dpcd struct for addresses 02200h through 0220Fh, and since so much of the data is a identical, simply overwrite the values stored in 00000h through 0000Fh with the values that can be overwritten from addresses 02200h through 0220Fh. This patch helps with backward compatibility for devices pre DP1.3. v2: read only dpcd values which can be affected, remove incorrect check, split into drm include changes into separate patch, commit message, verbose debugging statements during overwrite. v3: white space fixes v4: make path dependent on DPCD revision > 1.2 v5: split into function, removed DPCD rev check v6: add debugging prints for early exit conditions v7 (From Manasi): * Memcpy, memcmp and debig logging based on sizeof(dpcd_ext) (Jani N) * Exit early (Jani N) v8 (From Manasi): * Get rid of superfluous debug prints (Jani N) * Print entire base DPCD before memcpy (Jani N) v9 (From Manasi): * Add uniform newlines (Rodrigo) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Manasi Navare <manasi.d.navare@intel.com> Acked-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181129220058.19636-1-manasi.d.navare@intel.com
2018-12-05Makefile: fix mixed tab and spacesPedro Tammela
Fixes a comestic issue where spaces were being used instead of mixed tab and spaces. Signed-off-by: Pedro Tammela <pctammela@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181205110608.5513-1-pctammela@gmail.com
2018-12-04drm/i915/psr: Check if source supports sink specific SU granularityJosé Roberto de Souza
According to eDP spec, sink can required specific selective update granularity that source must comply. Here caching the value if required and checking if source supports it. v3: - Returning the default granularity in case DPCD read fails(Dhinakaran) - Changed DPCD error message level(Dhinakaran) v4: - Setting granularity to defaul when granularity read is equal to 0(Dhinakaran) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-9-jose.souza@intel.com
2018-12-04drm/i915/psr: Check if resolution is supported by default SU granularityJosé Roberto de Souza
Selective updates have a default granularity requirements as stated by eDP spec(PSR2 SELECTIVE UPDATE X GRANULARITY CAPABILITY register definition), so check if HW can match those requirements before enabling PSR2. v3: - Changes in the comments and commit message(Dhinakaran) - Printing the hdisplay that do not match with default granularity Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-8-jose.souza@intel.com
2018-12-04drm: Add the PSR SU granularity registers offsetsJosé Roberto de Souza
Source is required to comply to sink SU granularity when DP_PSR2_SU_GRANULARITY_REQUIRED is set in DP_PSR_CAPS, so adding the registers offsets. v2: Also adding DP_PSR2_SU_Y_GRANULARITY(Rodrigo) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-7-jose.souza@intel.com
2018-12-04drm/i915: Remove old PSR2 FIXME about frontbuffer trackingJosé Roberto de Souza
Our frontbuffer tracking improved over the years + the WA #0884 helped us keep PSR2 enabled while triggering screen updates when necessary so this FIXME is not valid anymore. Acked-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-6-jose.souza@intel.com
2018-12-04drm/i915/icl: Do not change reserved registers related to PSR2José Roberto de Souza
For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already unset in gen10 + GLK we can just drop it and fix for both gens. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-5-jose.souza@intel.com
2018-12-04drm/i915/psr: Enable sink to trigger a interruption on PSR2 CRC mismatchJosé Roberto de Souza
eDP spec states 2 different bits to enable sink to trigger a interruption when there is a CRC mismatch. DP_PSR_CRC_VERIFICATION is for PSR only and DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-4-jose.souza@intel.com
2018-12-04drm/i915/psr: Set PSR CRC verification bit in sink inside PSR1 blockJosé Roberto de Souza
As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {' and this bit is only set for PSR1 move it to that block to make it more easy to read. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-3-jose.souza@intel.com
2018-12-04drm/i915/psr: Don't tell sink that main link will be active while is active PSR2José Roberto de Souza
For PSR2 there is no register to tell HW to keep main link enabled while PSR2 is active, so don't configure sink DPCD with a misleading value. v2: Moving the set of DP_PSR_CRC_VERIFICATION to the else block of 'if (dev_priv->psr.psr2_enabled)' to another patch. (Rodrigo) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-2-jose.souza@intel.com
2018-12-04drm/i915: Disable PSR in Apple panelsJosé Roberto de Souza
i915 yet don't support PSR in Apple panels, so lets keep it disabled while we work on that. v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to DP_DPCD_QUIRK_NO_PSR (Ville) v3: Adding documentation to DP_DPCD_QUIRK_NO_PSR(Dhinakaran and Jani) Fixed typo in comment of the new quirk entry(Jani) Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204003403.23361-1-jose.souza@intel.com
2018-12-04drm/i915: Dial down workaround debug messagesTvrtko Ursulin
For selftests like live_hangcheck, which does thousands of reset per second, it is too verbose to log every time we re-apply the workarounds. Remove those messages since, coupled with the dedicated selftest, it is sufficient to only log the number of recorded workarounds at init time. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181204171530.28583-1-tvrtko.ursulin@linux.intel.com
2018-12-04drm/i915/selftests: Reorder request allocation vs vma pinningChris Wilson
Impose a restraint that we have all vma pinned for a request prior to its allocation. This is to simplify request construction, and should facilitate unravelling the lock interdependencies later. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-3-chris@chris-wilson.co.uk
2018-12-04drm/i915: Update DRIVER_DATE to 20181204Jani Nikula
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2018-12-04drm/i915/icl: fix transcoder state readoutJani Nikula
Commit 2ca711caeca2 ("drm/i915/icl: Consider DSI for getting transcoder state") clobbers the previously read TRANS_DDI_FUNC_CTL_EDP register contents with TRANS_DDI_FUNC_CTL_DSI0 contents. Fix the state readout, and handle DSI 1 while at it. Use a bitmask for iterating and logging transcoders, because the allowed combinations are a bit funky. Fixes: 2ca711caeca2 ("drm/i915/icl: Consider DSI for getting transcoder state") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108928 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204101926.17174-1-jani.nikula@intel.com
2018-12-04drm/i915: Allocate a common scratch pageChris Wilson
Currently we allocate a scratch page for each engine, but since we only ever write into it for post-sync operations, it is not exposed to userspace nor do we care for coherency. As we then do not care about its contents, we can use one page for all, reducing our allocations and avoid complications by not assuming per-engine isolation. For later use, it simplifies engine initialisation (by removing the allocation that required struct_mutex!) and means that we can always rely on there being a scratch page. v2: Check that we allocated a large enough scratch for I830 w/a Fixes: 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") # v4.18.20 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108850 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-1-chris@chris-wilson.co.uk Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.18.20+
2018-12-04drm/i915: Trim unused workaround list entriesTvrtko Ursulin
The new workaround list allocator grows the list in chunks so will end up with some unused space. Trim it when the initialization phase is done to free up a tiny bit of slab. v2: * Simplify with kmemdup. (Chris Wilson) v3: * Refactor for __size removal. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-8-tvrtko.ursulin@linux.intel.com
2018-12-04drm/i915: Fuse per-context workaround handling with the common frameworkTvrtko Ursulin
Convert the per context workaround handling code to run against the newly introduced common workaround framework and fuse the two to use the existing smarter list add helper, the one which does the sorted insert and merges registers where possible. This completes migration of all four classes of workarounds onto the common framework. Existing macros are kept untouched for smaller code churn. v2: * Rename to list name ctx_wa_list and move from dev_priv to engine. v3: * API rename and parameters tweaking. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133357.10341-1-tvrtko.ursulin@linux.intel.com
2018-12-04drm/i915: Move register white-listing to the common workaround frameworkTvrtko Ursulin
Instead of having a separate list of white-listed registers we can trivially move this to the common workarounds framework. This brings us one step closer to the goal of driving all workaround classes using the same code. v2: * Use GEM_DEBUG_WARN_ON for the sanity check. (Chris Wilson) v3: * API rename. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-6-tvrtko.ursulin@linux.intel.com
2018-12-04drm/i915/selftests: Add tests for GT and engine workaround verificationTvrtko Ursulin
Two simple selftests which test that both GT and engine workarounds are not lost after either a full GPU reset, or after the per-engine ones. (Including checks that one engine reset is not affecting workarounds not belonging to itself.) v2: * Rebase for series refactoring. * Add spinner for actual engine reset! * Add idle reset test as well. (Chris Wilson) * Share existing global_reset_lock. (Chris Wilson) v3: * intel_engine_verify_workarounds can be static. * API rename. (Chris Wilson) * Move global reset lock out of the loop. (Chris Wilson) v4: * Add missing rpm puts. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-5-tvrtko.ursulin@linux.intel.com
2018-12-04drm/i915: Verify GT workaround state after GPU initTvrtko Ursulin
Since we now have all the GT workarounds in a table, by adding a simple shared helper function we can now verify that their values are still applied after some interesting events in the lifetime of the driver. Initially we only do this after GPU initialization. v2: Chris Wilson: * Simplify verification by realizing it's a simple xor and and. * Remove verification from engine reset path. * Return bool straight away from the verify API. v3: * API rename. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-4-tvrtko.ursulin@linux.intel.com
2018-12-04drm/i915: Introduce per-engine workaroundsTvrtko Ursulin
We stopped re-applying the GT workarounds after engine reset since commit 59b449d5c82a ("drm/i915: Split out functions for different kinds of workarounds"). Issue with this is that some of the GT workarounds live in the MMIO space which gets lost during engine resets. So far the registers in 0x2xxx and 0xbxxx address range have been identified to be affected. This losing of applied workarounds has obvious negative effects and can even lead to hard system hangs (see the linked Bugzilla). Rather than just restoring this re-application, because we have also observed that it is not safe to just re-write all GT workarounds after engine resets (GPU might be live and weird hardware states can happen), we introduce a new class of per-engine workarounds and move only the affected GT workarounds over. Using the framework introduced in the previous patch, we therefore after engine reset, re-apply only the workarounds living in the affected MMIO address ranges. v2: * Move Wa_1406609255:icl to engine workarounds as well. * Rename API. (Chris Wilson) * Drop redundant IS_KABYLAKE. (Chris Wilson) * Re-order engine wa/ init so latest platforms are first. (Rodrigo Vivi) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=107945 Fixes: 59b449d5c82a ("drm/i915: Split out functions for different kinds of workarounds") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133341.10258-1-tvrtko.ursulin@linux.intel.com
generated by cgit (git 2.34.1) at 2025-05-30 10:21:36 +0000