- 15 Nov, 2022 1 commit
-
-
Jiri Slaby (SUSE) authored
The last user of macros from that include was removed in 2018 by the commit below. Fixes: 6cc42152 ("drm/i915: Remove support for legacy debugfs crc interface") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221115070302.4064-1-jirislaby@kernel.org
-
- 14 Nov, 2022 2 commits
-
-
Rodrigo Vivi authored
Catch up on 6.1-rc cycle in order to solve the intel_backlight conflict on linux-next. Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ben Skeggs authored
These are fixes from Lyude, and were meant to have been included in the last round of drm-next patches. - Fix some nasty memory issues that broke Lyude's display: - 0 initialize both nvif args and parsed HDMI infoframe buffers - Fixed missing memset(…, 0, …) for nvif args before sending VSI infoframe - Fixed incorrect data pointer and size in nvkm_uoutp_mthd_infoframe() (was previously pointing at the start of the nvif_outp_infoframe_args struct instead of at the start of the infoframe data - Get rid of duplicated scdc assignments, since we only use it to write the scdc registers Signed-off-by:Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 11 Nov, 2022 4 commits
-
-
Jani Nikula authored
Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Split out the display register helper macros to a separate file. For now, include it from i915_reg.h, but note that there are already files that don't need i915_reg.h, such as intel_audio.c. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
This is a more logical place for generic helpers. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
This is a more logical place for generic helpers. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
- 10 Nov, 2022 1 commit
-
-
Ville Syrjälä authored
Currently when opeating in split gamma mode we do the "skip ever other sw LUT entry" trick in the low level LUT programming/readout functions. That is very annoying and a big hinderance to revamping the color management uapi. Let's get rid of that problem by making half sized copies of the software LUTs and plugging those into the internal {pre,post}_csc_lut attachment points (instead of the sticking the uapi provide sw LUTs there directly). With this the low level stuff will operate purely in terms the hardware LUT sizes, and all uapi nonsense is contained to the atomic check phase. The one thing we do lose is intel_color_assert_luts() since we no longer have a way to check that the uapi LUTs were correctly used when generating the internal copies. But that seems like a price worth paying. Signed-off-by:Ankit Nautiyal <ankit.k.nautiyal@intel.com>
-
- 09 Nov, 2022 32 commits
-
-
Jani Nikula authored
struct intel_crtc_state in intel_display_types.h actually needs the struct intel_link_m_n definition, while intel_display.h only needs the forward declaration. Signed-off-by:
-
https://gitlab.freedesktop.org/skeggsb/nouveauDave Airlie authored
This is the pull request for a whole bunch of fixes and prep-work that was done to support Ampere acceleration prior to GSP-RM being available. It uses the ACR firmware released by NVIDIA in linux-firmware, as we do on earlier GPUs. The work to support running on top of GSP-RM also heavily depends on various pieces of this series. In addition to the new HW support, general stability of the driver should be improved, especially around recovering HW from bugs that can be generated by userspace driver components. Signed-off-by:
-
Ben Skeggs authored
v2: - whitespace Signed-off-by:
Gourav Samaiya <gsamaiya@nvidia.com>
-
Ben Skeggs authored
v2. fixup for ga103 early merge Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Ben Skeggs authored
v2. fixup for ga103 early merge Signed-off-by:
-
Ben Skeggs authored
v2. fixup for ga103 early merge Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
We weren't sending the high bits, though they're zero currently anyway. Signed-off-by:
-
Ben Skeggs authored
NVIDIA provided this on Turing, but we kept using the hardcoded version from Volta (where they didn't). Switch to the firmware version prior to Ampere. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
Essentially ripped verbatim from NVGPU, comments and all, and adapted to nvkm's structs and style. - maybe fixes an nvgpu bug though, a small tweak was needed to match RM v2: - remove unnecessary WARN_ON Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
We'll want to reuse the former for loading from proper netlist images. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
We're going to be pulling in a chunk of code from NVGPU to fixup our SMID mappings on Volta and above, which depends on ppc_nr[gpc] reflecting the actual number of PPCs present, not the maximum number. Signed-off-by:
-
Ben Skeggs authored
Ampere. Signed-off-by:
-
Ben Skeggs authored
Ampere. Signed-off-by:
-
Ben Skeggs authored
Ampere. Signed-off-by:
-
Ben Skeggs authored
Ampere. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
Match RM. Signed-off-by:
-
Ben Skeggs authored
This doesn't fix any known issue, but RM started doing it at some point, so presumably it's needed for something. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:
-
Ben Skeggs authored
This won't work on Ampere, and, it's questionable whether we should have been using our FW's method of storing the golden context image with NV's firmware to begin with. Signed-off-by:
-
Ben Skeggs authored
This doesn't work on Ampere for some reason, switch to directly modifying NV_PGRAPH_FECS_CTXSW_MAILBOX instead. Signed-off-by:
-
Ben Skeggs authored
This was thought to be per-channel initially - it's not. The backing pages for the VMM mappings are shared for all channels. - switches to more straight-forward patch interfaces - prepares for sub-context support - this is saving a *sizeable* amount of vram v2: - whitespace Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:
-
Ben Skeggs authored
This was thought to be per-channel initially - it's not. The backing pages for the VMM mappings are shared for all channels. - switches to more straight-forward patch interfaces - prepares for sub-context support Signed-off-by:
-
