[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here is the first PR for v5.12. There are quite a few patches accumulated after the holidays as usual: Most importantly there are fixes to the clear residual security mitigations to avoid GPU hangs caused by them. Further there is option to allow the user to decide to disable such mitigations similar to CPU side (i915.mitigations=auto,!residuals), if they are an expert user and wish to do so. Of course, usual caveats apply to disabling any security mitigations! For Tigerlake, a fix to reduce the likelihood of DMAR errors when IOMMU is enabled (MTBF bump from 10 secs to hours) and correction to detecting the device stepping. Addition of W/As for DG1 and TGL. Tuning the RPS algorithm further to limit to RPe on parking an engine. Plenty of refactoring, cleanups and optimizing code in preparation of upcoming series. The usual amount of selftest and documentation fixes. Then there are 3 other fixes for user reported/visible bugs; GPU hang due to wrong MOCS caching for index used by HW, false error message for case where GuC firmware doesn't load on first instance of the retry-loop and supplementing the GuC firmware table for Cometlake SKUs. Fixes for pre-emption on Gen8-era devices. Build and runtime fixes for 32-bit machines. Regards, Joonas PS. After you merge this, I will proceed to backmerge drm-next so that we can have a common topic branches for din and dign as requested by Jani and Rodrigo. *** drm-intel-gt-next-2021-01-14: UAPI Changes: - Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko) Avoid relying on last item ABI marker in i915_drm.h, add a comment to mark as deprecated. Driver Changes: - Restore clear residuals security mitigations for Ivybridge and Baytrail (Chris) - Close #1858: Allow sysadmin to choose applied GPU security mitigations through i915.mitigations=... similar to CPU (Chris) - Fix for #2024: GPU hangs on HSW GT1 (Chris) - Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville) - Fix for #2797: False positive GuC loading error message (Chris) - Fix for #2859: Missing GuC firmware for older Cometlakes (Chris) - Lessen probability of GPU hang due to DMAR faults [reason 7, next page table ptr is invalid] on Tigerlake (Chris) - Fix REVID macros for TGL to fetch correct stepping (Aditya) - Limit frequency drop to RPe on parking (Chris, Edward) - Limit W/A 1406941453 to TGL, RKL and DG1 (Swathi) - Make W/A 22010271021 permanent on DG1 (Lucas) - Implement W/A 16011163337 to prevent a HS/DS hang on DG1 (Swathi) - Only disable preemption on gen8 render engines (Chris) - Disable arbitration around Braswell's PDP updates (Chris) - Disable arbitration on no-preempt requests (Chris) - Check for arbitration after writing start seqno before busywaiting (Chris) - Retain default context state across shrinking (Venkata, CQ) - Fix mismatch between misplaced vma check and vma insert for 32-bit addressing userspaces (Chris, CQ) - Propagate error for vmap() failure instead kernel NULL deref (Chris) - Propagate error from cancelled submit due to context closure immediately (Chris) - Fix RCU race on HWSP tracking per request (Chris) - Clear CMD parser shadow and GPU reloc batches (Matt A) - Populate logical context during first pin (Maarten) - Optimistically prune dma-resv from the shrinker (Chris) - Fix for virtual engine ownership race (Chris) - Remove timeslice suppression to restore fairness for virtual engines (Chris) - Rearrange IVB/HSW workarounds properly between GT and engine (Chris) - Taint the reset mutex with the shrinker (Chris) - Replace direct submit with direct call to tasklet (Chris) - Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris) - Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko) - Use raw clock for RC6 time estimation in PMU (Tvrtko) - Differentiate OOM failures from invalid map types (Chris) - Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris) - Ignore repeated attempts to suspend request flow across reset (Chris) - Remove livelock from "do_idle_maps" VT-d W/A (Chris) - Cancel the preemption timeout early in case engine reset fails (Chris) - Code flow optimization in the scheduling code (Chris) - Clear the execlists timers upon reset (Chris) - Drain the breadcrumbs just once (Chris, Matt A) - Track the overall GT awake/busy time (Chris) - Tweak submission tasklet flushing to avoid starvation (Chris) - Track timelines created using the HWSP to restore on resume (Chris) - Use cmpxchg64 for 32b compatilibity for active tracking (Chris) - Prefer recycling an idle GGTT fence to avoid GPU wait (Chris) - Restructure GT code organization for clearer split between GuC and execlists (Chris, Daniele, John, Matt A) - Remove GuC code that will remain unused by new interfaces (Matt B) - Restructure the CS timestamp clocks code to local to GT (Chris) - Fix error return paths in perf code (Zhang) - Replace idr_init() by idr_init_base() in perf (Deepak) - Fix shmem_pin_map error p
Re: reminder: review of maintainer-tools patches is mandatory
On Thu, 14 Jan 2021 at 12:15, Daniel Vetter wrote: > On Thu, Jan 14, 2021 at 12:21 PM Daniel Stone wrote: > > On Thu, 14 Jan 2021 at 07:15, Jani Nikula wrote: > > > On Wed, 13 Jan 2021, Daniel Vetter wrote: > > > > Yeah with proper MR flow we'd have marge set up (to do the MR merging > > > > for us, it's a bot), which adds a Part-of: tag to each commit it > > > > pushes through an MR, so you can go back to the MR link and see all > > > > the discussion. There's an r-b: tag from me there. I think we should > > > > either set that up or disable MR since it's confusing. > > > > > > I think as a project maintainer-tools is now so detached and independent > > > from the kernel git flows that we can move to support merge requests > > > here if you like. All in, or support both patches and merge requests? > > If we go MR I'd say MR-only, since that'll stop me from failing to run > make check, which I'm way too guilty of :-/ > > > Takes about 5 minutes to set Marge up and we can enforce it so only > > Marge can push as well. Let me know if you want that done. > > Afaiui maintainers/owners can still force push and everything, and > Marge is just for developers? Does marge then check for whether you > have commit rights or not? There are a few ways to skin that cat. We can mark the branches as protected so indeed maintainers/owners could force push. We could install a pre-update hook to reject pushes from Marge unless you explicitly pass a Git option in the environment (like we have for dim-protected repos). Or ... probably something else. Cheers, Daniel ___ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
Re: reminder: review of maintainer-tools patches is mandatory
Hi Jani,
Apologies on this - I understand the review part as well, you're right.
Just to give you context: This patch was a quick response to Daniel's ask
to update the documentation over IRC. I didn't know the process for this,
and assuming gitlab, created a PR. By the time I could offer Daniel to send
a patch, he had merged the PR.
Irrespective, I will take care going forward. Apologies again.
Best,
Sumit.
On Wed, Jan 13, 2021 at 7:01 PM Jani Nikula wrote:
>
> Hi Sumit, I just noticed commit 3ed2489ca753 ("Update repositories.rst
> for current drm-misc maintainers") in the maintainer-tools repository.
>
> The change appears to have been pushed without first sending the patch
> to the dim-tools mailing list, and apparently without review.
>
> Regardless of how trivial or minor the change appears to be, review is
> mandatory. For that to happen, posting to the mailing list is mandatory.
>
> Please see CONTRIBUTING.rst in the repository.
>
> ---
>
> As to the change, the review, given the chance, would have been that the
> change is not enough. We still seem to have Sean's email in the dim
> script.
>
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>
___
dim-tools mailing list
dim-tools@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools
Re: reminder: review of maintainer-tools patches is mandatory
On Thu, Jan 14, 2021 at 12:21 PM Daniel Stone wrote: > On Thu, 14 Jan 2021 at 07:15, Jani Nikula wrote: > > On Wed, 13 Jan 2021, Daniel Vetter wrote: > > > Yeah with proper MR flow we'd have marge set up (to do the MR merging > > > for us, it's a bot), which adds a Part-of: tag to each commit it > > > pushes through an MR, so you can go back to the MR link and see all > > > the discussion. There's an r-b: tag from me there. I think we should > > > either set that up or disable MR since it's confusing. > > > > I think as a project maintainer-tools is now so detached and independent > > from the kernel git flows that we can move to support merge requests > > here if you like. All in, or support both patches and merge requests? If we go MR I'd say MR-only, since that'll stop me from failing to run make check, which I'm way too guilty of :-/ > Takes about 5 minutes to set Marge up and we can enforce it so only > Marge can push as well. Let me know if you want that done. Afaiui maintainers/owners can still force push and everything, and Marge is just for developers? Does marge then check for whether you have commit rights or not? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
Re: reminder: review of maintainer-tools patches is mandatory
On Thu, 14 Jan 2021 at 07:15, Jani Nikula wrote: > On Wed, 13 Jan 2021, Daniel Vetter wrote: > > Yeah with proper MR flow we'd have marge set up (to do the MR merging > > for us, it's a bot), which adds a Part-of: tag to each commit it > > pushes through an MR, so you can go back to the MR link and see all > > the discussion. There's an r-b: tag from me there. I think we should > > either set that up or disable MR since it's confusing. > > I think as a project maintainer-tools is now so detached and independent > from the kernel git flows that we can move to support merge requests > here if you like. All in, or support both patches and merge requests? Takes about 5 minutes to set Marge up and we can enforce it so only Marge can push as well. Let me know if you want that done. Cheers, Daniel ___ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2021-01-14: drm/i915 fixes for v5.11-rc4: - Allow the sysadmin to override security mitigations - Restore clear-residual mitigations for ivb/byt - Limit VFE threads based on GT - GVT: fix vfio edid and full display detection - Fix DSI DSC power refcounting - Fix LPT CPU mode backlight takeover - Disable RPM wakeref assertions during driver shutdown - Fix DSI sequence sleeps BR, Jani. The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-01-14 for you to fetch changes up to 984cadea032b103c5824a5f29d0a36b3e9df6333: drm/i915: Allow the sysadmin to override security mitigations (2021-01-12 19:03:40 +0200) drm/i915 fixes for v5.11-rc4: - Allow the sysadmin to override security mitigations - Restore clear-residual mitigations for ivb/byt - Limit VFE threads based on GT - GVT: fix vfio edid and full display detection - Fix DSI DSC power refcounting - Fix LPT CPU mode backlight takeover - Disable RPM wakeref assertions during driver shutdown - Fix DSI sequence sleeps Chris Wilson (4): drm/i915: Disable RPM wakeref assertions during driver shutdown drm/i915/gt: Limit VFE threads based on GT drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail drm/i915: Allow the sysadmin to override security mitigations Colin Xu (1): drm/i915/gvt: Fix vfio_edid issue for BXT/APL Hans de Goede (1): drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence Imre Deak (1): drm/i915/icl: Fix initing the DSI DSC power refcount during HW readout Jani Nikula (2): drm/i915/backlight: fix CPU mode backlight takeover on LPT Merge tag 'gvt-fixes-2020-01-08' of https://github.com/intel/gvt-linux into drm-intel-fixes drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/icl_dsi.c | 4 - drivers/gpu/drm/i915/display/intel_panel.c | 9 +- drivers/gpu/drm/i915/display/vlv_dsi.c | 16 ++- drivers/gpu/drm/i915/gt/gen7_renderclear.c | 157 ++-- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 6 +- drivers/gpu/drm/i915/gvt/display.c | 81 drivers/gpu/drm/i915/gvt/vgpu.c | 5 +- drivers/gpu/drm/i915/i915_drv.c | 4 + drivers/gpu/drm/i915/i915_mitigations.c | 146 ++ drivers/gpu/drm/i915/i915_mitigations.h | 13 ++ 11 files changed, 339 insertions(+), 103 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_mitigations.c create mode 100644 drivers/gpu/drm/i915/i915_mitigations.h -- Jani Nikula, Intel Open Source Graphics Center ___ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
