Imre Deak [Mon, 14 Nov 2022 12:22:44 +0000 (14:22 +0200)]
drm/i915: Preallocate the debug power domain wakerefs array
Since the current size of intel_display_power_domain_set struct is
close to 1kB, it's better to use preallocated memory for it. The only
user of the intel_display_power_get/put_in_set() allocating the struct
on stack is hsw_get_pipe_config(), so we can avoid potential stack
overallocations by moving the struct here to the preallocated
intel_crtc struct (hsw_get_pipe_config() is non-reentrant wrt. each
CRTC).
This patch replaces
https://lore.kernel.org/intel-gfx/20221107170917.3566758-5-imre.deak@intel.com/T/#md3f6cdf17fcd
Imre Deak [Mon, 14 Nov 2022 12:22:43 +0000 (14:22 +0200)]
drm/i915: Fix warn in intel_display_power_*_domain() functions
The intel_display_power_*_domain() functions should always warn if a
default domain is returned as a fallback, fix this up. Spotted by Ville.
Fixes: 979e1b32e0e2 ("drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platform") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221114122251.21327-2-imre.deak@intel.com
Ville Syrjälä [Tue, 8 Nov 2022 15:18:27 +0000 (17:18 +0200)]
drm/i915/audio: Unify get_saved_enc()
Make the two branches of get_saved_enc() look alike. Currently
they look different even though they do exactly the same thing
apart from == vs. != for the MST comparison.
Ville Syrjälä [Mon, 7 Nov 2022 19:46:02 +0000 (21:46 +0200)]
drm/i915: Treat HDMI as DVI when cloning
When doing HDMI+non-HDMI cloning the other sink can't get
the infoframes/etc. so stuff like limited range output is
not a good idea.
Similarly when doing HDMI+HDMI cloning on g4x (only platform
where we allow it) only one of the ports can receive infoframes
and so again using any fancy stuff is a bad idea. We also don't
track the inforames/audio state per-port so we'd end up with
some kind of random mismash state when multipled encoders try
to compute the same stuff. And the hardware will in fact
automagically disable audio/infoframe transmission if you try
to enable it for multiple HDMI ports at the same time.
Thus disable all HDMI specific features when cloning.
Ville Syrjälä [Mon, 14 Nov 2022 15:37:15 +0000 (17:37 +0200)]
drm/i915: Clean up 12.4bit precision palette defines
Use consistent bit definitions for the 12.4bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the icl+ superfine segment defines (and we also
already pointed to them from the ivb+ precision palette defines).
Also use the these appropriately in the LUT entry pack/unpack
functions.
Ville Syrjälä [Mon, 14 Nov 2022 15:37:14 +0000 (17:37 +0200)]
drm/i915: Clean up 10bit precision palette defines
Use consistent bit definitions for the 10bit precision palette bits.
We just define these alongside the ilk/snb register definitions and
point to those from the ivb+ defines.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Ville Syrjälä [Mon, 14 Nov 2022 15:37:13 +0000 (17:37 +0200)]
drm/i915: Clean up legacy palette defines
Use consistent bit definitions for the legacy gamma LUT. We just
define these alongside the pre-ilk register definitions and point
to those from the ilk+ defines.
Also use the these appropriately in the LUT entry pack/unpack
functions.
Ville Syrjälä [Fri, 11 Nov 2022 12:31:18 +0000 (14:31 +0200)]
drm/i915: Print plane name in fbc tracepoints
Print the name of the plane in the fbc tracepoints. As the
pipe<->plane assignment can vary on old hw it's probably
more helpful to see both the plane and the pipe names together.
Ville Syrjälä [Fri, 11 Nov 2022 12:31:17 +0000 (14:31 +0200)]
drm/i915: Pass intel_plane to plane tracepoints
Pass intel_plane rather than drm_plane to the plane tracepoints.
Matches what we do eg. with the fbc tracepoints. Using the same
type for everything will help with digging out the device name
from the plane in the future.
Jani Nikula [Wed, 16 Nov 2022 15:06:57 +0000 (17:06 +0200)]
drm/i915/edp: wait power off delay at driver remove to optimize probe
Panel power off delay is the time the panel power needs to remain off
after being switched off, before it can be switched on again.
For the purpose of respecting panel power off delay at driver probe,
assuming the panel was last switched off at driver probe is overly
pessimistic. If the panel was never on, we'd end up waiting for no
reason.
We don't know what has happened before kernel boot, but we can make some
assumptions:
- The panel may have been switched off right before kernel boot by some
pre-os environment.
- After kernel boot, the panel may only be switched off by i915.
- At i915 driver probe, only a previously loaded and removed i915 may
have switched the panel power off.
With these assumptions, we can initialize the last power off time to
kernel boot time, if we also ensure i915 driver remove waits for the
panel power off delay after switching panel power off.
This shaves off the time it takes from kernel boot to i915 probe from
the first panel enable, if (and only if) the panel was not already
enabled at boot.
The encoder destroy hook is pretty much the last place where we can
wait, right after we've ensured the panel power has been switched off,
and before the whole encoder is destroyed.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7417 Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Lee Shawn C <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221116150657.1347504-1-jani.nikula@intel.com
Zhi Wang [Fri, 4 Nov 2022 14:56:50 +0000 (14:56 +0000)]
drm/i915/gvt: remove the vgpu->released and its sanity check
The life cycle of a vGPU, which is represented by a vfio_device, has been
managed by the VFIO core logic. Remove the vgpu->released, which was used
for a sanity check on the removal path of the vGPU instance. The sanity
check has already been covered in the VFIO core logic.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: intel-gvt-dev@lists.freedesktop.org Suggested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20221104145652.1570-1-zhi.a.wang@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
i915/gvt: remove hardcoded value on crc32_start calculation
struct gvt_firmware_header has a crc32 member in which all members that
come after the that field are used to calculate it. The previous
implementation added the value '4' (crc32's u32 size) to calculate the
crc32_start offset which came across as a bit cryptic until you take a
deeper look at the struct.
This patch changes crc32_start offset to the 'version' member which is
the first member of the struct gvt_firmware_header after crc32.
It's worth mentioning that doing a build before/after this patch results
in no binary output differences.
Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.
Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting prototype for inte_gvt_free_vgpu_resource(). Prototype was for intel_vgpu_free_resource() instead
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting prototype for intel_alloc_vgpu_resource(). Prototype was for intel_vgpu_alloc_resource() instead
drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype for intel_vgpu_emulate_cfg_read(). Prototype was for intel_vgpu_emulate_cfg_write() instead
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'info' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'kref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'initref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'list' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype for intel_t_default_mmio_write(). Prototype was for intel_vgpu_default_mmio_write() instead
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting prototype for intel_gvt_switch_render_mmio(). Prototype was for intel_gvt_switch_mmio() instead
drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype for intel_vgpu_enable_page_track(). Prototype was for intel_vgpu_disable_page_track() instead
drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu() instead
There is a spelling mistake in a gvt_vgpu_err error message. Fix it.
Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.king@gmail.com Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
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>
Jani Nikula [Wed, 9 Nov 2022 15:35:22 +0000 (17:35 +0200)]
drm/i915: stop including i915_irq.h from i915_trace.h
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.
Jani Nikula [Wed, 9 Nov 2022 15:35:21 +0000 (17:35 +0200)]
drm/i915: split out intel_display_reg_defs.h
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.
Ville Syrjälä [Wed, 26 Oct 2022 11:39:06 +0000 (14:39 +0300)]
drm/i915: Create resized LUTs for ivb+ split gamma mode
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.
Jani Nikula [Wed, 2 Nov 2022 10:08:24 +0000 (12:08 +0200)]
drm/i915/display: move struct intel_link_m_n to intel_display_types.h
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.
Dave Airlie [Wed, 9 Nov 2022 00:48:44 +0000 (10:48 +1000)]
Merge branch '00.06-gr-ampere' of https://gitlab.freedesktop.org/skeggsb/nouveau into drm-next
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.
Ben Skeggs [Wed, 1 Jun 2022 10:48:14 +0000 (20:48 +1000)]
drm/nouveau/gr/gf117-: make ppc_nr[gpc] accurate
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 <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
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 <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:52 +0000 (20:47 +1000)]
drm/nouveau/acr: use common falcon HS FW code for ACR FWs
Adds context binding and support for FWs with a bootloader to the code
that was added to load VPR scrubber HS binaries, and ports ACR over to
using all of it.
- gv100 split from gp108 to handle FW exit status differences
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:52 +0000 (20:47 +1000)]
drm/nouveau/fb/gp102-: unlock VPR right after devinit
Under memory load, instmem allocations could end up in the regions of
VRAM that are inaccessible right after boot, and be corrupted after a
suspend/resume cycle as a result of being restored before booting the
mem unlock firmware.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:51 +0000 (20:47 +1000)]
drm/nouveau/flcn: new code to load+boot simple HS FWs (VPR scrubber)
Adds the start of common interfaces to load and boot the HS binaries
provided by NVIDIA that enable the usage of GR.
ACR already handles most of this, but it's very much tied into ACR's
init process, and there's other code that could benefit from reusing
a lot of this stuff too (ie. VBIOS DEVINIT/PreOS, VPR scrubber).
The VPR scrubber code is fairly independent, and a good first target.
- adds better debug output to fw loading process, to ease bring-up/debug
v2:
- whitespace, 0->false
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:51 +0000 (20:47 +1000)]
drm/nouveau/flcn: rework falcon reset
Mostly preparation to fit in Ampere changes, but should result in reset
sequences a lot closer to RM's, and perhaps help out with the issues we
sometimes see reported in this area.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:38 +0000 (20:47 +1000)]
drm/nouveau/fifo: add new channel classes
Exposes a bunch of the new features that became possible as a result
of the earlier commits. DRM will build on this in the future to add
support for features such as SCG ("async compute") and multi-device
rendering, as part of the work necessary to be able to write a half-
decent vulkan driver - finally.
For the moment, this just crudely ports DRM to the API changes.
- channel class interfaces now the same for all HW classes
- channel group class exposed (SCG)
- channel runqueue selector exposed (SCG)
- channel sub-device id control exposed (multi-device rendering)
- channel names in logging will reflect creating process, not fd owner
- explicit USERD allocation required by VOLTA_CHANNEL_GPFIFO_A and newer
- drm is smarter about determining the appropriate channel class to use
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:35 +0000 (20:47 +1000)]
drm/nouveau/fifo: add common runlist control
- less dependence on waiting for runlist updates, on GPUs that allow it
- supports runqueue selector in RAMRL entries
- completes switch to common runl/cgrp/chan topology info
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:34 +0000 (20:47 +1000)]
drm/nouveau/fifo: add common channel recovery
That sure was fun to untangle.
- handled per-runlist, rather than globally
- more straight-forward process in general
- various potential SW/HW races have been fixed
- fixes lockdep issues that were present in >=gk104's prior implementation
- volta recovery now actually stands a chance of working
- volta/turing waiting for PBDMA idle before engine reset
- turing using hw-provided TSG info for CTXSW_TIMEOUT
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:33 +0000 (20:47 +1000)]
drm/nouveau/fifo: kill channel on a selection of PBDMA errors
A bunch of these can be handled in such a way that the channel can
continue, however, any of these are a pretty decent sign something
has gone horribly wrong, and the safest option is to disable the
channel.
This is a bit of a hack, we will want to handle these individually
and dump relevant debug info for each at some point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
Ben Skeggs [Wed, 1 Jun 2022 10:47:32 +0000 (20:47 +1000)]
drm/nouveau/fifo: add chan start()/stop()
- nvkm_chan_error() built on top, stops channel and sends 'killed' event
- removes an odd double-bashing of channel enable regs on kepler and up
- pokes doorbell on turing and up, after enabling channel
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
projects / mirror_ubuntu-kernels.git / log