kernel/linux.git/drivers/gpu/drm/i915, branch v5.10.28

drm/i915: Fix the GT fence revocation runtime PM logic

2021-03-30T12:31:55+00:00

commit 8840e3bd981f128846b01c12d3966d115e8617c9 upstream. To optimize some task deferring it until runtime resume unless someone holds a runtime PM reference (because in this case the task can be done w/o the overhead of runtime resume), we have to use the runtime PM get-if-active logic: If the runtime PM usage count is 0 (and so get-if-in-use would return false) the runtime suspend handler is not necessarily called yet (it could be just pending), so the device is not necessarily powered down, and so the runtime resume handler is not guaranteed to be called. The fence revocation depends on the above deferral, so add a get-if-active helper and use it during fence revocation. v2: - Add code comment explaining the fence reg programming deferral logic to i915_vma_revoke_fence(). (Chris) - Add Cc: stable and Fixes: tags. (Chris) - Fix the function docbook comment. Cc: Chris Wilson Cc: # v4.12+ Fixes: 181df2d458f3 ("drm/i915: Take rpm wakelock for releasing the fence on unbind") Reviewed-by: Chris Wilson Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20210322204223.919936-1-imre.deak@intel.com (cherry picked from commit 9d58aa46291d4d696bb1eac3436d3118f7bf2573) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman

i915/perf: Start hrtimer only if sampling the OA buffer

2021-03-25T08:04:08+00:00

commit 6a77c6bb7260bd5000f95df454d9f8cdb1af7132 upstream. SAMPLE_OA parameter enables sampling of OA buffer and results in a call to init the OA buffer which initializes the OA unit head/tail pointers. The OA_EXPONENT parameter controls the periodicity of the OA reports in the OA buffer and results in starting a hrtimer. Before gen12, all use cases required the use of the OA buffer and i915 enforced this setting when vetting out the parameters passed. In these platforms the hrtimer was enabled if OA_EXPONENT was passed. This worked fine since it was implied that SAMPLE_OA is always passed. With gen12, this changed. Users can use perf without enabling the OA buffer as in OAR use cases. While an OAR use case should ideally not start the hrtimer, we see that passing an OA_EXPONENT parameter will start the hrtimer even though SAMPLE_OA is not specified. This results in an uninitialized OA buffer, so the head/tail pointers used to track the buffer are zero. This itself does not fail, but if we ran a use-case that SAMPLED the OA buffer previously, then the OA_TAIL register is still pointing to an old value. When the timer callback runs, it ends up calculating a wrong/large number of available reports. Since we do a spinlock_irq_save and start processing a large number of reports, NMI watchdog fires and causes a crash. Start the timer only if SAMPLE_OA is specified. v2: - Drop SAMPLE OA check when appending samples (Ashutosh) - Prevent read if OA buffer is not being sampled Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Ashutosh Dixit Signed-off-by: Lionel Landwerlin Link: https://patchwork.freedesktop.org/patch/msgid/20210305210947.58751-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit be0bdd67fda9468156c733976688f6487d0c42f7) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Wedge the GPU if command parser setup fails

2021-03-17T16:06:19+00:00

commit a829f033e966d5e4aa27c3ef2b381f51734e4a7f upstream. Commit 311a50e76a33 ("drm/i915: Add support for mandatory cmdparsing") introduced mandatory command parsing but setup failures were not translated into wedging the GPU which was probably the intent. Possible errors come in two categories. Either the sanity check on internal tables has failed, which should be caught in CI unless an affected platform would be missed in testing; or memory allocation failure happened during driver load, which should be extremely unlikely but for correctness should still be handled. v2: * Tidy coding style. (Chris) [airlied: cherry-picked to avoid rc1 base] Signed-off-by: Tvrtko Ursulin Fixes: 311a50e76a33 ("drm/i915: Add support for mandatory cmdparsing") Cc: Jon Bloomfield Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20210302114213.1102223-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 5a1a659762d35a6dc51047c9127c011303c77b7f) Signed-off-by: Rodrigo Vivi Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: Reject 446-480MHz HDMI clock on GLK

2021-03-04T10:38:46+00:00

commit 7a6c6243b44a439bda4bf099032be35ebcf53406 upstream. The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola (cherry picked from commit 41751b3e5c1ac656a86f8d45a8891115281b729e) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman

drm/i915/gt: Correct surface base address for renderclear

2021-03-04T10:38:31+00:00

commit 81ce8f04aa96f7f6cae05770f68b5d15be91f5a2 upstream. The surface_state_base is an offset into the batch, so we need to pass the correct batch address for STATE_BASE_ADDRESS. Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Prathap Kumar Valsan Cc: Akeem G Abodunrin Cc: Hans de Goede Cc: Hans de Goede Reviewed-by: Mika Kuoppala Cc: # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20210210122728.20097-1-chris@chris-wilson.co.uk (cherry picked from commit 1914911f4aa08ddc05bae71d3516419463e0c567) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman

drm/i915/gt: Flush before changing register state

2021-03-04T10:38:30+00:00

commit d5109f739c9f14a3bda249cb48b16de1065932f0 upstream. Flush; invalidate; change registers; invalidate; flush. Will this finally work on every device? Or will Baytrail complain again? On the positive side, we immediately see the benefit of having hsw-gt1 in CI. Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") Testcase: igt/gem_render_tiled_blits # hsw-gt1 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Akeem G Abodunrin Acked-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20210125220247.31701-1-chris@chris-wilson.co.uk (cherry picked from commit d30bbd62b1bfd9e0a33c3583c5a9e5d66f60cbd7) Signed-off-by: Rodrigo Vivi Cc: Diego Calleja Cc: Hans de Goede Signed-off-by: Greg Kroah-Hartman

drm/i915/gt: One more flush for Baytrail clear residuals

2021-03-04T10:37:19+00:00

commit e627d5923cae93fa4188f4c4afba6486169a1337 upstream. CI reports that Baytail requires one more invalidate after CACHE_MODE for it to be happy. Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Akeem G Abodunrin Reviewed-by: Mika Kuoppala Reviewed-by: Akeem G Abodunrin Cc: Hans de Goede Cc: Diego Calleja Link: https://patchwork.freedesktop.org/patch/msgid/20210119110802.22228-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman

drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it

2021-02-17T10:02:21+00:00

commit 2f51312bebb77962a518b4c6de777dd378b6110a upstream. The TypeC FIA can be powered down if the TC-COLD power state is allowed, so block the TC-COLD state when initializing the FIA. Note that this isn't needed on ICL where the FIA is never modular and which has no generic way to block TC-COLD (except for platforms with a legacy TypeC port and on those too only via these legacy ports, not via a DP-alt/TBT port). Cc: # v5.10+ Cc: José Roberto de Souza Reported-by: Paul Menzel Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027 Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20210208154303.6839-1-imre.deak@intel.com Reviewed-by: Jos� Roberto de Souza (cherry picked from commit f48993e5d26b079e8c80fff002499a213dbdb1b4) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix overlay frontbuffer tracking

2021-02-17T10:02:21+00:00

commit 5feba0e905c495a217aea9db4ea91093d8fe5dde upstream. We don't have a persistent fb holding a reference to the frontbuffer object, so every time we do the get+put we throw the frontbuffer object immediately away. And so the next time around we get a pristine frontbuffer object with bits==0 even for the old vma. This confuses the frontbuffer tracking code which understandably expects the old frontbuffer to have the overlay's bit set. Fix this by hanging on to the frontbuffer reference until the next flip. And just to make this a bit more clear let's track the frontbuffer explicitly instead of just grabbing it via the old vma. Cc: stable@vger.kernel.org Cc: Chris Wilson Cc: Joonas Lahtinen Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-2-ville.syrjala@linux.intel.com Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking") Reviewed-by: Chris Wilson (cherry picked from commit 553c23bdb4775130f333f07a51b047276bc53f79) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Skip vswing programming for TBT

2021-02-13T12:55:16+00:00

commit eaf5bfe37db871031232d2bf2535b6ca92afbad8 upstream. In thunderbolt mode the PHY is owned by the thunderbolt controller. We are not supposed to touch it. So skip the vswing programming as well (we already skipped the other steps not applicable to TBT). Touching this stuff could supposedly interfere with the PHY programming done by the thunderbolt controller. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak (cherry picked from commit f8c6b615b921d8a1bcd74870f9105e62b0bceff3) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman