In addition to the already defined REQUEST HXG message format,
which is used when sender expects some confirmation or data,
HXG protocol includes definition of the FAST REQUEST message,
that may be used when sender does not expect any useful data
to be returned.
Using this instead of GUC_HXG_TYPE_EVENT for non-blocking CTB requests
will allow GuC to send back GUC_HXG_TYPE_RESPONSE_FAILURE in case of
errors.
Note that it is not possible to return such errors to the caller,
since this is for non-blocking calls and the related fence is not
stored. Instead such messages are treated as unexpected, which will
give an indication of potential GuC misprogramming that warrants extra
debugging effort.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230526235538.2230780-2-John.C.Harrison@Intel.com
Allow compute contexts to submit the maximal amount of work without
blocking userspace.
The original size for user LRC ring's (SZ_16K) was chosen to minimise
memory consumption, without being so small as to frequently stall in the
middle of workloads. With the main consumers being GL / media pipelines
of 2 or 3 batches per frame, we want to support ~10 requests in flight
to allow for the application to control throttling without stalling
within a frame.
v2:
- cover with else part
Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230517135754.1110291-1-tejas.upadhyay@intel.com
VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, with less precisions/range. In fact CHV also has the WGC
but using it there doesn't really make sense when you have the
superior CGM CSC around.
Hook up the necessary stuff to expose the WGC as the CTM
crtc property.
One additional crazy idea that came to mind would be to use
the WGC as an output CSC on CHV for YCbCr output. But it
would be incompatible with the legacy LUT usage. In fact
since the WGC lacks post-offsets we'd probably have to
use the legacy LUT to do that final part of the RGB->YCbCr
conversion. Sounds doable, but perhaps not worth the hassle.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413164916.4221-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
On CHV toggling the CGM CSC on/off while the pipe is running leads
to underruns. Looks like we'd have to do the toggling strictly inside
the start_of_vblank-frame_start window to avoid this, but that window
is less than a scanline so there's no way we can guarantee hitting it.
As a workaround let's just leave the CGM CSC permanently enabled.
Fortunately the CGM gamma/degamma units don't seem to suffer from
this malady.
I also tried turning off CGM unit clock gating, but that did not
help.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413164916.4221-5-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
For platforms with GMD_ID support (i.e., everything MTL and beyond),
identification of the display IP present should be based on the contents
of the GMD_ID register rather than a PCI devid match.
Note that since GMD_ID readout requires access to the PCI BAR, a slight
change to the driver init sequence is needed --- pci_enable_device() is
now called before i915_driver_create().
v2:
- Fix use of uninitialized i915 pointer in error path if
pci_enable_device() fails before the i915 device is created. (lkp)
- Use drm_device parameter to intel_display_device_probe. This goes
against i915 conventions, but since the primary goal here is to make
it easy to call this function from other drivers (like Xe) and since
we don't need anything from the i915 structure, this seems like an
exception where drm_device is a more natural fit.
v3:
- Go back do drm_i915_private for intel_display_device_probe. (Jani)
- Move forward decl to top of header. (Jani)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-6-matthew.d.roper@intel.com
Rather than selecting the display IP and feature flags at the same time
the general PCI probing happens, move this step into the display code
itself so that it can be more easily re-used outside of i915 (i.e., by
the Xe driver).
v2:
- Make intel_display_device_probe() always return a non-NULL pointer
and simplify copying of runtime_defaults. (Andrzej)
v3:
- Redefine INTEL_VGA_DEVICE/INTEL_QUANTA_DEVICE to eliminate a cast and
an include of linux/mod_devicetable.h. (Jani)
- Keep explicit memcpy for runtime defaults. (Jani)
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-5-matthew.d.roper@intel.com
Rather than embeddeding the display's device info within the main device
info structure, just provide a pointer to the display-specific
structure. This is in preparation for moving the display device info
definitions into the display code itself and for eventually allowing the
pointer to be assigned at runtime on platforms that use GMD_ID for
device identification.
In the future, this will also eventually allow the same display device
info structures to be used outside the current i915 code (e.g., from the
Xe driver).
v2:
- Move introduction of DISPLAY_INFO() to this patch. (Andrzej)
v3:
- Also use DISPLAY_INFO() in intel_display_reg_defs.h. (Andrzej)
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-3-matthew.d.roper@intel.com
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
cache. For userspace components needing to fine tune the caching policy
for BO's, a follow up patch will extend the GEM_CREATE uAPI to allow
them specify caching mode at BO creation time.
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230519051103.3404990-2-fei.yang@intel.com
Reserve some bits in the counter config namespace which will carry the
tile id and prepare the code to handle this.
No per tile counters have been added yet.
v2:
- Fix checkpatch issues
- Use 4 bits for gt id in non-engine counters. Drop FIXME.
- Set MAX GTs to 4. Drop FIXME.
v3: (Ashutosh, Tvrtko)
- Drop BUG_ON that would never fire
- Make enable u64
- Pull in some code from next patch
v4: Set I915_PMU_MAX_GTS to 2 (Tvrtko)
v5: s/u64/u32 where needed (Ashutosh)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230519154946.3751971-7-umesh.nerlige.ramappa@intel.com
For a bigjoiner configuration display->crtc_disable() will be called
first for the slave CRTCs and then for the master CRTC. However slave
CRTCs will be actually disabled only after the master CRTC is disabled
(from the encoder disable hooks called with the master CRTC state).
Hence the slave PIPEDMCs can be disabled only after the master CRTC is
disabled, make this so.
intel_encoders_post_pll_disable() must be called only for the master
CRTC, as for the other two encoder disable hooks. While at it fix this
up as well. This didn't cause a problem, since
intel_encoders_post_pll_disable() will call the corresponding hook only
for an encoder/connector connected to the given CRTC, however slave
CRTCs will have no associated encoder/connector.
Fixes: 3af2ff0840 ("drm/i915: Enable a PIPEDMC whenever its corresponding pipe is enabled")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-2-imre.deak@intel.com
(cherry picked from commit 7eeef32719)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Like DG2, MTL a-step hardware is subject to Wa_16014892111 which
requires that any changes made to the DRAW_WATERMARK register be
done via an INDIRECT_CTX batch buffer rather than through a regular
context workaround.
The bspec gives the same non-default recommended tuning value
for DRAW_WATERMARK as DG2, so we can re-use the INDIRECT_CTX code
to apply that tuning setting on A-step hardware.
Application of the tuning setting on B-step and later does not
need INDIRECT_CTX handling and is already done in
mtl_ctx_workarounds_init() as usual.
v2: Limit the WA for A-step
v3: Update the commit message.
v4: Reorder platform checks and update commit message.
Bspec: 68331
Cc: Haridhar Kalvala <haridhar.kalvala@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230517233111.297542-2-radhakrishna.sripada@intel.com
