- 03 May, 2024 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-xe-next-fixes-2024-05-02' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Fix for a backmerge going slightly wrong. - An UAF fix - Avoid a WA error on LNL. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZjOijQA43zhu3SZ4@fedora
-
- 02 May, 2024 4 commits
-
-
Lucas De Marchi authored
In order to detect duplicate implementations for the same workaround, early in the implementation of RTP it was decided to error out even if the values set are exactly the same. With the introduction of 18034896535 in commit 74671d23 ("drm/xe/xe2: Add workaround 18034896535"), LNL stepping with graphics stepping A1 now gives the following error on module load: xe 0000:00:02.0: [drm] *ERROR* GT0: [GT OTHER] \ discarding save-restore reg e48c (clear: 00000200, set: 00000200,\ masked: yes, mcr: yes): ret=-22 RTP may be improved in the future, but for now simply join the entries like done with e.g. "1607297627, 1607030317, 1607186500". Fixes: 74671d23 ("drm/xe/xe2: Add workaround 18034896535") Cc: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240427135339.3485559-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 4caf4107) Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
Matthew Auld authored
We flush the rebind worker during the vm close phase, however in places like preempt_fence_work_func() we seem to queue the rebind worker without first checking if the vm has already been closed. The concern here is the vm being closed with the worker flushed, but then being rearmed later, which looks like potential uaf, since there is no actual refcounting to track the queued worker. We can't take the vm->lock here in preempt_rebind_work_func() to first check if the vm is closed since that will deadlock, so instead flush the worker again when the vm refcount reaches zero. v2: - Grabbing vm->lock in the preempt worker creates a deadlock, so checking the closed state is tricky. Instead flush the worker when the refcount reaches zero. It should be impossible to queue the preempt worker without already holding vm ref. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1676 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1591 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1364 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1304 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1249Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423074721.119633-4-matthew.auld@intel.com (cherry picked from commit 3d44d67c) Signed-off-by:
-
Thomas Hellström authored
The recent backmerge from drm-next to drm-xe-next brought with it some silent unexpected results. One code snippet was added twice and a partial revert had merge errors. Fix that up to reinstate the affected code as it was before the backmerge. v2: - Commit log message rewording (Lucas DeMarchi) Fixes: 79790b68 ("Merge drm/drm-next into drm-xe-next") Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2024-04-30' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-next Core DRM: - Export drm_client_dev_unregister (Thomas Zimmermann) Display i915: - More initial work to make display code more independent from i915 (Jani) - Convert i915/xe fbdev to DRM client (Thomas Zimmermann) - VLV/CHV DPIO register cleanup (Ville) Signed-off-by:
-
- 30 Apr, 2024 23 commits
-
-
Ville Syrjälä authored
Pull the VLV/CHV DPIO PHY sideband registers to their own file. v2: drop stray tabs (Jani) Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240422083457.23815-15-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use REG_BIT() & co. for the vlv/chv DPIO PHY registers. Note that DPIO_BIAS_CURRENT_CTL_SHIFT was incorrectly defined to be 21 wheres 20 is the correct value. It is not used in the code though so didn't bother splitting to a separate patch. v2: drop stray tabs (Jani) Signed-off-by:
-
Ville Syrjälä authored
The DPIO PHY registers follow clear numbering rules. Express those in a few macros to get rid of the hand calculated final offsets. Signed-off-by:
-
Ville Syrjälä authored
Drop the leading underscore from the CHV PHY common lane register definitions. We use these directly from actual code so the underscore here is misleading as usually it indicates an intermediate define that shouldn't be used directly. Signed-off-by:
-
Ville Syrjälä authored
Include _GRP in VLV DPIO PHY group access register define names. Makes it more obvious where the accesses will land. Also matches the naming used by BXT already. Signed-off-by:
-
Ville Syrjälä authored
In the encoder hooks we are dealing primarily with the encoder, so derive the DPIO PHY from the encoder rather than the pipe. Technically this doesn't matter as we can't cross connect pipes<->port across PHY boundaries, but it does conveny the intention more accurately. Signed-off-by:
-
Ville Syrjälä authored
Stop using 'pipe' directly as the DPIO PHY channel. This does happen to work on VLV since it just has the one PHY with CH0==pipe A and CH1==pipe B. But explicitly converting the thing to the right enum makes the whole thing less confusing. Signed-off-by:
-
Ville Syrjälä authored
Stop calling the DPIO PHY channel "port". Just say "ch", which is already used in a bunch of places. Signed-off-by:
-
Ville Syrjälä authored
Use a consistent 'tmp' as the variable name for the register values during rmw when we don't deal with multiple registers in parallel. Signed-off-by:
-
Ville Syrjälä authored
Drop all the local variables for the DPLL dividers for vlv/chv and just consult the state directly. Signed-off-by:
-
Ville Syrjälä authored
The spreadsheet defines the PLL register block as having the dwords in the following order: block dwords offsets PLL1 0x0-0x7 0x00-0x1f PLL2 0x0-0x7 0x20-0x3f PLL1ext 0x10-0x1f 0x40-0x5f PLL2ext 0x10-0x1f 0x60-0x7f So dword indexes 0x8-0xf don't even exist. Renumber our register defines to match. Note that the spreadsheet used hex numbering whereas our defiens are in decimal. Perhaps we should change that? Signed-off-by:
-
Ville Syrjälä authored
VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address does kinda look like it goes to the PLL block on a first glance, but broadcast is special and doesn't even exist for the PLL (only PCS and TX have it). The fact that we use a broadcast write here is a bit sketchy IMO since we're now blasting the register to all PCS splines across the whole PHY. So the PCS registers in the other channel (ie. other pipe/port) will also be written. But I guess the fact that we always write the same value should make this a nop even if the other channel is already enabled (assuming the VBIOS/GOP didn't screw up and use some other value...). Signed-off-by:
-
Ville Syrjälä authored
Our VLV_REF_DW13 is actually VLV_REF_DW11. Rename it. Signed-off-by:
-
Ville Syrjälä authored
We don't use the result of the VLV_PCS01_DW8 read at all, so don't read. Signed-off-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C22 register macro. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0a07f615c574040094b37c861078e41daf53c706.1714399071.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C21_C20 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C12 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C11_C10 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C02 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PIPE_WGC_C01_C00 register macro. Reviewed-by:
-
Jani Nikula authored
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PALETTE register macro. Reviewed-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-6.10-2024-04-26' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.10-2024-04-26: amdgpu: - Misc code cleanups and refactors - Support setting reset method at runtime - Report OD status - SMU 14.0.1 fixes - SDMA 4.4.2 fixes - VPE fixes - MES fixes - Update BO eviction priorities - UMSCH fixes - Reset fixes - Freesync fixes - GFXIP 9.4.3 fixes - SDMA 5.2 fixes - MES UAF fix - RAS updates - Devcoredump updates for dumping IP state - DSC fixes - JPEG fix - Fix VRAM memory accounting - VCN 5.0 fixes - MES fixes - UMC 12.0 updates - Modify contiguous flags handling - Initial support for mapping kernel queues via MES amdkfd: - Fix rescheduling of restore worker - VRAM accounting for SVM migrations - mGPU fix - Enable SQ watchpoint for gfx10 Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2024-04-26' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-next UAPI Changes: - drm/i915/guc: Use context hints for GT frequency Allow user to provide a low latency context hint. When set, KMD sends a hint to GuC which results in special handling for this context. SLPC will ramp the GT frequency aggressively every time it switches to this context. The down freq threshold will also be lower so GuC will ramp down the GT freq for this context more slowly. We also disable waitboost for this context as that will interfere with the strategy. We need to enable the use of SLPC Compute strategy during init, but it will apply only to contexts that set this bit during context creation. Userland can check whether this feature is supported using a new param- I915_PARAM_HAS_CONTEXT_FREQ_HINT. This flag is true for all guc submission enabled platforms as they use SLPC for frequency management. The Mesa usage model for this flag is here - https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint - drm/i915/gt: Enable only one CCS for compute workload Enable only one CCS engine by default with all the compute sices allocated to it. While generating the list of UABI engines to be exposed to the user, exclude any additional CCS engines beyond the first instance *** NOTE: This W/A will make all DG2 SKUs appear like single CCS SKUs by default to mitigate a hardware bug. All the EUs will still remain usable, and all the userspace drivers have been confirmed to be able to dynamically detect the change in number of CCS engines and adjust. For the smaller percent of applications that get perf benefit from letting the userspace driver dispatch across all 4 CCS engines we will be introducing a sysfs control as a later patch to choose 4 CCS each with 25% EUs (or 50% if 2 CCS). NOTE: A regression has been reported at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895 However Andi has been triaging the issue and we're closing in a fix to the gap in the W/A implementation: https://lists.freedesktop.org/archives/intel-gfx/2024-April/348747.html Driver Changes: - Add new and fix to existing workarounds: Wa_14018575942 (MTL), Wa_16019325821 (Gen12.70), Wa_14019159160 (MTL), Wa_16015675438, Wa_14020495402 (Gen12.70) (Tejas, John, Lucas) - Fix UAF on destroy against retire race and remove two earlier partial fixes (Janusz) - Limit the reserved VM space to only the platforms that need it (Andi) - Reset queue_priority_hint on parking for execlist platforms (Chris) - Fix gt reset with GuC submission is disabled (Nirmoy) - Correct capture of EIR register on hang (John) - Remove usage of the deprecated ida_simple_xx() API - Refactor confusing __intel_gt_reset() (Nirmoy) - Fix the fix for GuC reset lock confusion (John) - Simplify/extend platform check for Wa_14018913170 (John) - Replace dev_priv with i915 (Andi) - Add and use gt_to_guc() wrapper (Andi) - Remove bogus null check (Rodrigo, Dan) . Selftest improvements (Janusz, Nirmoy, Daniele) Signed-off-by:
-
- 29 Apr, 2024 5 commits
-
-
Daniel Vetter authored
Thomas needs the defio fixes, Maíra needs the vkms fixes and Joonas has some fun with i915-gem conflicts. Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Clean up i915_reg.h. v2: Drop a redundant comment (Ville) Reviewed-by:
-
Jani Nikula authored
Clean up i915_reg.h. v2: Drop chicken regs and comments (Ville) Reviewed-by:
-
Jani Nikula authored
For some reason the paletter registers were missed when adding intel_color_regs.h. Finish the job. Adjust some comments while at it. v2: Fix comments (Ville) Reviewed-by:
-
Jani Nikula authored
There are too few registers to warrant a dedicated file for LPE audio regs, but the audio reg file is better than i915_reg.h. v2: Rebase Reviewed-by:
-
- 28 Apr, 2024 6 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Ingo Molnar: - Fix EEVDF corner cases - Fix two nohz_full= related bugs that can cause boot crashes and warnings * tag 'sched-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU sched/isolation: Prevent boot crash when the boot CPU is nohz_full sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() sched/eevdf: Fix miscalculation in reweight_entity() when se is not curr sched/eevdf: Always update V if se->on_rq when reweighting
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: - Make the CPU_MITIGATIONS=n interaction with conflicting mitigation-enabling boot parameters a bit saner. - Re-enable CPU mitigations by default on non-x86 - Fix TDX shared bit propagation on mprotect() - Fix potential show_regs() system hang when PKE initialization is not fully finished yet. - Add the 0x10-0x1f model IDs to the Zen5 range - Harden #VC instruction emulation some more * tag 'x86-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n cpu: Re-enable CPU mitigations by default for !X86 architectures x86/tdx: Preserve shared bit on mprotect() x86/cpu: Fix check for RDPKRU in __show_regs() x86/CPU/AMD: Add models 0x10-0x1f to the Zen5 range x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fix from Ingo Molnar: "Fix a double free bug in the init error path of the GICv3 irqchip driver" * tag 'irq-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Prevent double free on error
-
Oleg Nesterov authored
housekeeping_setup() checks cpumask_intersects(present, online) to ensure that the kernel will have at least one housekeeping CPU after smp_init(), but this doesn't work if the maxcpus= kernel parameter limits the number of processors available after bootup. For example, a kernel with "maxcpus=2 nohz_full=0-2" parameters crashes at boot time on a virtual machine with 4 CPUs. Change housekeeping_setup() to use cpumask_first_and() and check that the returned CPU number is valid and less than setup_max_cpus. Another corner case is "nohz_full=0" on a machine with a single CPU or with the maxcpus=1 kernel argument. In this case non_housekeeping_mask is empty and tick_nohz_full_setup() makes no sense. And indeed, the kernel hits the WARN_ON(tick_nohz_full_running) in tick_sched_do_timer(). And how should the kernel interpret the "nohz_full=" parameter? It should be silently ignored, but currently cpulist_parse() happily returns the empty cpumask and this leads to the same problem. Change housekeeping_setup() to check cpumask_empty(non_housekeeping_mask) and do nothing in this case. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Reviewed-by:
Phil Auld <pauld@redhat.com> Acked-by:
Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20240413141746.GA10008@redhat.com
-
Oleg Nesterov authored
Documentation/timers/no_hz.rst states that the "nohz_full=" mask must not include the boot CPU, which is no longer true after: 08ae95f4 ("nohz_full: Allow the boot CPU to be nohz_full"). However after: aae17ebb ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") the kernel will crash at boot time in this case; housekeeping_any_cpu() returns an invalid CPU number until smp_init() brings the first housekeeping CPU up. Change housekeeping_any_cpu() to check the result of cpumask_any_and() and return smp_processor_id() in this case. This is just the simple and backportable workaround which fixes the symptom, but smp_processor_id() at boot time should be safe at least for type == HK_TYPE_TIMER, this more or less matches the tick_do_timer_boot_cpu logic. There is no worry about cpu_down(); tick_nohz_cpu_down() will not allow to offline tick_do_timer_cpu (the 1st online housekeeping CPU). Fixes: aae17ebb ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") Reported-by:
Chris von Recklinghausen <crecklin@redhat.com> Signed-off-by:
-
- 27 Apr, 2024 1 commit
-
-
https://github.com/Rust-for-Linux/linuxLinus Torvalds authored
Pull Rust fixes from Miguel Ojeda: - Soundness: make internal functions generated by the 'module!' macro inaccessible, do not implement 'Zeroable' for 'Infallible' and require 'Send' for the 'Module' trait. - Build: avoid errors with "empty" files and workaround 'rustdoc' ICE. - Kconfig: depend on '!CFI_CLANG' and avoid selecting 'CONSTRUCTORS'. - Code docs: remove non-existing key from 'module!' macro example. - Docs: trivial rendering fix in arch table. * tag 'rust-fixes-6.9' of https://github.com/Rust-for-Linux/linux: rust: remove `params` from `module` macro example kbuild: rust: force `alloc` extern to allow "empty" Rust files kbuild: rust: remove unneeded `@rustc_cfg` to avoid ICE rust: kernel: require `Send` for `Module` implementations rust: phy: implement `Send` for `Registration` rust: make mutually exclusive with CFI_CLANG rust: macros: fix soundness issue in `module!` macro rust: init: remove impl Zeroable for Infallible docs: rust: fix improper rendering in Arch Support page rust: don't select CONSTRUCTORS
-
