drm/i915: preparation for using PAT index

This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.

Preparing the transition by adding some platform dependent data structures
and helper functions to translate the cache_level to pat_index.

cachelevel_to_pat: a platform dependent array mapping cache_level to
                   pat_index.

max_pat_index: the maximum PAT index recommended in hardware specification
               Needed for validating the PAT index passed in from user
               space.

i915_gem_get_pat_index: function to convert cache_level to PAT index.

obj_to_i915(obj): macro moved to header file for wider usage.

I915_MAX_CACHE_LEVEL: upper bound of i915_cache_level for the
                      convenience of coding.

Cc: Chris Wilson <[email protected]>
Cc: Matt Roper <[email protected]>
Signed-off-by: Fei Yang <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Fix the wa number for Wa_22016670082

Fixes the right lineage number for the workaround.

Fixes: a7fa1537b791 ("drm/i915/mtl: Implement Wa_14019141245")
Cc: Matt Roper <[email protected]>
Signed-off-by: Radhakrishna Sripada <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Tejas Upadhyay <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Add MTL for remapping CCS FBs

Add support for remapping CCS FBs on MTL to remove the restriction
of the power-of-two sized stride and the 2MB surface offset alignment
for these FBs.

Signed-off-by: Clint Taylor <[email protected]>
Signed-off-by: Juha-Pekka Heikkila <[email protected]>
Reviewed-by: Radhakrishna Sripada <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Drop FLAT CCS check

Remove FLAT CCS check from XY_FAST_COLOR_BLT usage, thus
enabling MTL to use it.

Signed-off-by: Pallavi Mishra <[email protected]>
Signed-off-by: Juha-Pekka Heikkila <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/uc: Make unexpected firmware versions an error in debug builds

If the DEBUG_GEM config option is set then escalate the 'unexpected
firmware version' message from a notice to an error. This will ensure
that the CI system treats such occurences as a failure and logs a bug
about it (or fails the pre-merge testing).

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/uc: Reject duplicate entries in firmware table

It was noticed that duplicate entries in the firmware table could cause
an infinite loop in the firmware loading code if that entry failed to
load. Duplicate entries are a bug anyway and so should never happen.
Ensure they don't by tweaking the table validation code to reject
duplicates.

For full m/m/p files, that can be done by simply tweaking the patch
level check to reject matching values. For reduced version entries,
the filename itself must be compared.

v2: Improve comment (review by Daniele)

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/uc: Enhancements to firmware table validation

The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out into a separate function that is only
called once per blob type at init time.

Also, drop the CONFIG_SELFTEST requirement and make errors terminal.
It was mentioned that potential issues with backports would not be
caught by regular pre-merge CI as that only occurs on tip not stable
branches. Making the validation unconditional and failing driver load
on detecting of a problem ensures that such backports will also be
validated correctly.

This requires adding a firmware global flag to indicate an issue with
any of the per firmware tables. This is done rather than adding a new
state enum as a new enum value would be a much more invasive change -
lots of places would need updating to support the new error state.

Note also that this change means that a table error will cause the
driver to wedge even on platforms that don't require firmware files.
This is intentional as per the above backport concern - someone doing
backports is not guaranteed to test on every platform that they may
potential affect. So forcing a failure on all platforms ensures that
the problem will be noticed and corrected immediately.

v2: Change to unconditionally fail module load on a validation error
(review feedback/discussion with Daniele).
v3: Add a new flag to track table validation errors (review
feedback/discussion with Daniele).

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Print status register when waiting for GuC to load

If the GuC load is taking an excessively long time, the wait loop
currently prints the GT frequency. Extend that to include the GuC
status as well so we can see if the GuC is actually making progress or
not.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Decode another GuC load failure case

Explain another potential firmware failure mode and early exit the
long wait if hit.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Define GuC firmware version for MTL

First release of GuC for Meteorlake.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Lucas De Marchi <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/uc: Track patch level versions on reduced version firmware files

When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification reported if it was older. However,
the patch version should really be tracked as well for the same
reasons. The KMD can work without the change but if the effort has
been taken to release a new firmware with the change then there must
be a valid reason for doing so - important bug fix, security fix, etc.
And in that case it would be good to alert the user if they are
missing out on that new fix.

v2: Use correct patch version number and drop redunant debug print
(review by Daniele / CI results).

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915: use kernel-doc -Werror when CONFIG_DRM_I915_WERROR=y

With CONFIG_DRM_I915_WERROR=y, we enable kernel-doc check for both
objects and headers. Now that the kernel-doc warnings have been fixed,
also enable kernel-doc -Werror to fail the build on kernel-doc warnings.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/68ffcad0e6ff2b6cd70c6df28822f967898ce197.1683041799.git.jani.nikula@intel.com

drm/i915/ttm: fix i915_ttm_to_gem() kernel-doc

drivers/gpu/drm/i915/gem/i915_gem_ttm.h:50: warning: Function parameter or member 'bo' not described in 'i915_ttm_to_gem'

v2: Fix return value documentation while at it (Rodrigo)

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/scatterlist: fix kernel-doc

Can't document function pointer members as if they are functions.

drivers/gpu/drm/i915/i915_scatterlist.h:160: warning: Incorrect use of kernel-doc format:          * release() - Free the memory of the struct i915_refct_sgt

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/a0c099707ec4f1911b14b0f286848a298b2b29e0.1683041799.git.jani.nikula@intel.com

drm/i915/gem: fix function pointer member kernel-doc

You can't document function pointer member as functions.

drivers/gpu/drm/i915/gem/i915_gem_region.h:25: warning: Incorrect use of kernel-doc format:          * process_obj - Process the current object
drivers/gpu/drm/i915/gem/i915_gem_region.h:35: warning: Function parameter or member 'process_obj' not described in 'i915_gem_apply_to_region_ops'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/a2a81f9ee78591def0534c81a63dbc652c44bbd3.1683041799.git.jani.nikula@intel.com

drm/i915/vma: fix struct i915_vma_bindinfo kernel-doc

You can't document both a sub-struct type and a struct member at the
same time. Separate them.

drivers/gpu/drm/i915/i915_vma_resource.h:91: warning: Incorrect use of kernel-doc format:          * struct i915_vma_bindinfo - Information needed for async bind
drivers/gpu/drm/i915/i915_vma_resource.h:129: warning: Function parameter or member 'bi' not described in 'i915_vma_resource'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/89ab5cf179566c429383cc57db746038f75cba0d.1683041799.git.jani.nikula@intel.com

drm/i915/gsc: add support for GSC proxy interrupt

The GSC notifies us of a proxy request via the HECI2 interrupt. The
interrupt must be enabled both in the HECI layer and in our usual gt irq
programming; for the latter, the interrupt is enabled via the same enable
register as the GSC CS, but it does have its own mask register. When the
interrupt is received, we also need to de-assert it in both layers.

The handling of the proxy request is deferred to the same worker that we
use for GSC load. New flags have been added to distinguish between the
init case and the proxy interrupt.

v2: Make sure not to set the reset bit when enabling/disabling the GSC
interrupts, fix defines (Alan)

v3: rebase on proxy status register check

Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Alan Previn <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/gsc: add initial support for GSC proxy

The GSC uC needs to communicate with the CSME to perform certain
operations. Since the GSC can't perform this communication directly
on platforms where it is integrated in GT, i915 needs to transfer the
messages from GSC to CSME and back.
The proxy flow is as follow:
1 - i915 submits a request to GSC asking for the message to CSME
2 - GSC replies with the proxy header + payload for CSME
3 - i915 sends the reply from GSC as-is to CSME via the mei proxy
    component
4 - CSME replies with the proxy header + payload for GSC
5 - i915 submits a request to GSC with the reply from CSME
6 - GSC replies either with a new header + payload (same as step 2,
    so we restart from there) or with an end message.

After GSC load, i915 is expected to start the first proxy message chain,
while all subsequent ones will be triggered by the GSC via interrupt.

To communicate with the CSME, we use a dedicated mei component, which
means that we need to wait for it to bind before we can initialize the
proxies. This usually happens quite fast, but given that there is a
chance that we'll have to wait a few seconds the GSC work has been moved
to a dedicated WQ to not stall other processes.

v2: fix code style, includes and variable naming (Alan)
v3: add extra check for proxy status, fix includes and comments

Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Cc: Alan Previn <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

mei: gsc_proxy: add gsc proxy driver

Add GSC proxy driver. It to allows messaging between GSC component
on Intel graphics card and CSE device.

Cc: Alan Previn <[email protected]>
Signed-off-by: Alexander Usyskin <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Define GSC Proxy component interface

GSC Proxy component is used for communication between the
Intel graphics driver and MEI driver.

Cc: Alan Previn <[email protected]>
Signed-off-by: Alexander Usyskin <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/scatterlist: fix kernel-doc parameter documentation

drivers/gpu/drm/i915/i915_scatterlist.h:164: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops'
drivers/gpu/drm/i915/i915_scatterlist.h:187: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put'
drivers/gpu/drm/i915/i915_scatterlist.h:198: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get'
drivers/gpu/drm/i915/i915_scatterlist.h:214: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/0b31edbb33116c8002dd1e72d3ad25efe5dd0176.1683041799.git.jani.nikula@intel.com

drm/i915/pxp: fix kernel-doc for member dev_link

Add /** to make it a kernel-doc.

drivers/gpu/drm/i915/pxp/intel_pxp_types.h:96: warning: Function parameter or member 'dev_link' not described in 'intel_pxp'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/84f89a3332fa323888f1e3241fb51ae10417ecd7.1683041799.git.jani.nikula@intel.com

drm/i915/pmu: drop kernel-doc

The comments are closer to not being kernel-doc.

drivers/gpu/drm/i915/i915_pmu.h:21: warning: cannot understand function prototype: 'enum i915_pmu_tracked_events '
drivers/gpu/drm/i915/i915_pmu.h:32: warning: cannot understand function prototype: 'enum '
drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * How many different events we track in the global PMU mask.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/7656b8f58b088c108a2a32f7089329740efabba1.1683041799.git.jani.nikula@intel.com

drm/i915/active: fix kernel-doc for function parameters

drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init'
drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init'
drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init'
drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set'
drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set'
drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get'
drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/7f201c6cb715e4b3cece78ffa893a75610ecd27d.1683041799.git.jani.nikula@intel.com

drm/i915/guc: add intel_guc_state_capture member docs for ads_null_cache and max_mmio_per_node

drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'ads_null_cache' not described in 'intel_guc_state_capture'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'max_mmio_per_node' not described in 'intel_guc_state_capture'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c83878163221ed3684a6de5d5e1c5373ddd5c06f.1683041799.git.jani.nikula@intel.com

drm/i915/guc: drop lots of kernel-doc markers

The documentation is closer to not being kernel-doc, so just drop the
kernel-doc markers.

drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'size' not described in '__guc_capture_bufstate'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'data' not described in '__guc_capture_bufstate'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'rd' not described in '__guc_capture_bufstate'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'wr' not described in '__guc_capture_bufstate'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'link' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'is_partial' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_class' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_inst' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'guc_id' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'lrca' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'reginfo' not described in '__guc_capture_parsed_output'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line:
 * struct guc_debug_capture_list_header / struct guc_debug_capture_list
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:80: warning: wrong kernel-doc identifier on line:
 * struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:105: warning: wrong kernel-doc identifier on line:
 * struct guc_state_capture_header_t / struct guc_state_capture_t /
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'is_valid' not described in '__guc_capture_ads_cache'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'ptr' not described in '__guc_capture_ads_cache'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'size' not described in '__guc_capture_ads_cache'
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'status' not described in '__guc_capture_ads_cache'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'marker' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'read_ptr' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'write_ptr' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'size' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'sampled_write_ptr' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'wrap_offset' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flush_to_file' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'buffer_full_cnt' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'reserved' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flags' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'version' not described in 'guc_log_buffer_state'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/9c210d53fdbd6da5fac42e435855d269504919d7.1683041799.git.jani.nikula@intel.com

drm/i915/guc: add dbgfs_node member kernel-doc

drivers/gpu/drm/i915/gt/uc/intel_guc.h:274: warning: Function parameter or member 'dbgfs_node' not described in 'intel_guc'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/b0f681dd82289dd86da78c6242411e8d812e51a1.1683041799.git.jani.nikula@intel.com

drm/i915/engine: hide preempt_hang selftest member from kernel-doc

drivers/gpu/drm/i915/gt/intel_engine_types.h:293: warning: Function parameter or member 'preempt_hang' not described in 'intel_engine_execlists'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/dafd771bb75cf14965dd3b666987c58a438de134.1683041799.git.jani.nikula@intel.com

drm/i915/gtt: fix i915_vm_resv_put() kernel-doc parameter name

drivers/gpu/drm/i915/gt/intel_gtt.h:515: warning: Function parameter or member 'vm' not described in 'i915_vm_resv_put'
drivers/gpu/drm/i915/gt/intel_gtt.h:515: warning: Excess function parameter 'resv' description in 'i915_vm_resv_put'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c22e58e770019667980b3617f6e963b76d7e79a7.1683041799.git.jani.nikula@intel.com

drm/i915/context: fix kernel-doc parameter descriptions

drivers/gpu/drm/i915/gt/intel_context.h:108: warning: Function parameter or member 'ce' not described in 'intel_context_lock_pinned'
drivers/gpu/drm/i915/gt/intel_context.h:123: warning: Function parameter or member 'ce' not described in 'intel_context_is_pinned'
drivers/gpu/drm/i915/gt/intel_context.h:142: warning: Function parameter or member 'ce' not described in 'intel_context_unlock_pinned'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/8359a1cef6b5ab268a9dcc1a382281b6e39cfa64.1683041799.git.jani.nikula@intel.com

drm/i915/engine: fix kernel-doc function name for intel_engine_cleanup_common()

drivers/gpu/drm/i915/gt/intel_engine_cs.c:1525: warning: expecting prototype for intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() instead

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/33f8dfdf38be3e16675971e6983e3e300d4301a6.1683041799.git.jani.nikula@intel.com

drm/i915/gem: fix i915_gem_object_lookup_rcu() kernel-doc parameter name

drivers/gpu/drm/i915/gem/i915_gem_object.h:94: warning: Function parameter or member 'file' not described in 'i915_gem_object_lookup_rcu'
drivers/gpu/drm/i915/gem/i915_gem_object.h:94: warning: Excess function parameter 'filp' description in 'i915_gem_object_lookup_rcu'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/80c96863b7a0755aaa07efb49bcccd9ba620c6d7.1683041799.git.jani.nikula@intel.com

drm/i915/request: drop kernel-doc

The documentation is closer to not being kernel-doc. Just drop the
kernel-doc /** indicators.

drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Request queue structure.
drivers/gpu/drm/i915/i915_request.h:477: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Returns true if seq1 is later than seq2.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/62a7a0f6e5b33e59ef4339304d01e7ef7ee04430.1683041799.git.jani.nikula@intel.com

drm/i915/error: fix i915_capture_error_state() kernel-doc

drivers/gpu/drm/i915/i915_gpu_error.c:2174: warning: Function parameter or member 'dump_flags' not described in 'i915_capture_error_state'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20524292b002800975d82d23b5bd47da878f1733.1683041799.git.jani.nikula@intel.com

drm/i915/perf: fix i915_perf_ioctl_version() kernel-doc

drivers/gpu/drm/i915/i915_perf.c:5307: warning: Function parameter or member 'i915' not described in 'i915_perf_ioctl_version'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/b93ddb95a15d1376936349b32c7facb35c76be82.1683041799.git.jani.nikula@intel.com

drm/i915/vma: document struct i915_vma_resource wakeref member

drivers/gpu/drm/i915/i915_vma_resource.h:129: warning: Function parameter or member 'wakeref' not described in 'i915_vma_resource'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/50389365e095dc564ab5f1f1e3647934163ffefa.1683041799.git.jani.nikula@intel.com

drm/i915/utils: drop kernel-doc from __wait_for()

The parameters aren't documented, and the file isn't included in Sphinx
build anyway, so demote the kernel-doc to a regular comment.

drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'OP' not described in '__wait_for'
drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'COND' not described in '__wait_for'
drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'US' not described in '__wait_for'
drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'Wmin' not described in '__wait_for'
drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'Wmax' not described in '__wait_for'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/e6e33a7f03c4a78739fa96e6ae74eb272ae147e7.1683041799.git.jani.nikula@intel.com

drm/i915/vma: fix kernel-doc function name for i915_vma_size()

drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/9fd58398ba6f86c55cc7a7c62efeab70c3311d59.1683041799.git.jani.nikula@intel.com

drm/i915/gvt: fix intel_vgpu_alloc_resource() kernel-doc parameter

drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: Function parameter or member 'conf' not described in 'intel_vgpu_alloc_resource'
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: Excess function parameter 'param' description in 'intel_vgpu_alloc_resource'

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/9213214c9caa296ebd349a5d5b44c2bbb45cdf99.1683041799.git.jani.nikula@intel.com

drm/i915/guc: Fix error capture for virtual engines

GuC based register dumps in error capture logs were basically broken
for virtual engines. This can be seen in igt@gem_exec_balancer@hang:
  [IGT] gem_exec_balancer: starting subtest hang
  [drm] GPU HANG: ecode 12:4:e1524110, in gem_exec_balanc [6388]
  [drm] GT0: GUC: No register capture node found for 0x1005 / 0xFEDC311D
  [drm] GPU HANG: ecode 12:4:00000000, in gem_exec_balanc [6388]
  [IGT] gem_exec_balancer: exiting, ret=0

The test causes a hang on both engines of a virtual engine context.
The engine instance zero hang gets a valid error capture but the
non-instance-zero hang does not.

Fix that by scanning through the list of pending register captures
when a hang notification for a virtual engine is received. That way,
the hang can be assigned to the correct physical engine prior to
starting the error capture process. So later on, when the error capture
handler tries to find the engine register list, it looks for one on
the correct engine.

Also, sneak in a missing blank line before a comment in the node
search code.

v2: Fix null pointer deref on non-GuC platforms.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Capture list naming clean up

Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.

Don't add Xe only GSC registers to pre-Xe devices that don't
even have a GSC engine.

Fix Xe_LP name.

Don't use GEN9 as a prefix for register lists that contain all GEN8
registers.

Rename the 'default_' register list prefix to 'gen8_' as that is the
more accurate name.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Consolidate duplicated capture list code

Remove 99% duplicated steered register list code. Also, include the
pre-Xe steered registers in the pre-Xe list generation.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Don't capture Gen8 regs on Xe devices

A pair of pre-Xe registers were being included in the Xe capture list.
GuC was rejecting those as being invalid and logging errors about
them. So, stop doing it.

Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Alan Previn <[email protected]>
Fixes: dce2bd542337 ("drm/i915/guc: Add Gen9 registers for GuC error state capture.")
Cc: Alan Previn <[email protected]>
Cc: Umesh Nerlige Ramappa <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: John Harrison <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: Balasubramani Vivekanandan <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/selftests: Use gt_err for GT info

It will be more informative regarding
GT if we use gt_err instead.

Cc: Andi Shyti <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/gt: Use gt_err for GT info

It will be more informative regarding
GT if we use gt_err instead.

Cc: Andi Shyti <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/fdinfo: Enable fdinfo for GuC backends

Enable fdinfo for GuC based platforms with the exception that long
running contexts will not provide reliable busyness data unless they
switch out at some reasonable point in time.

Link: https://gitlab.freedesktop.org/drm/intel/issues/8303
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Ashutosh Dixit <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

i915/pmu: Add support for total context runtime for GuC back-end

GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
in the context image. This value is saved/restored on context switches.
KMD accumulates these values into a 64 bit counter taking care of any
overflows as needed. This count provides the basis for client specific
busyness in the fdinfo interface.

KMD accumulation happens just before the context is unpinned and when
context switches out. This works for execlist back-end since execlist
scheduling has visibility into context switches. With GuC mode, KMD does
not have visibility into context switches and this counter is
accumulated only when context is unpinned. Context is unpinned once the
context scheduling is successfully disabled. Disabling context
scheduling is an asynchronous operation. Also if a context is servicing
frequent requests, scheduling may never be disabled on it.

For GuC mode, since updates to the context runtime may be delayed, add
hooks to update the context runtime in a worker thread as well as when
a user queries for it.

Limitation:
- If a context is never switched out or runs for a long period of time,
  the runtime value of CTX_TIMESTAMP may never be updated, so the
  counter value may be unreliable. This patch does not support such
  cases. Such support must be available from the GuC FW and it is WIP.

This patch is an extract from previous work authored by John/Umesh here -
https://patchwork.freedesktop.org/patch/496441/?series=105085&rev=4

v2: (Ashutosh)
- Drop COPS_RUNTIME_ACTIVE_TOTAL
- s/guc_context_update_clks/__guc_context_update_stats
- Pin context before accessing in guc_timestamp_ping
- In guc_context_unpin, use spinlock to serialize access to runtime stats

Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Co-developed-by: John Harrison <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Reviewed-by: Ashutosh Dixit <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/rc6: throw out set() wrapper

Remove useless indirection that's just misdirection for the readers.

Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/selftest: Update the SLPC selftest

Use the new efficient frequency toggling interface. Also
create a helper function to restore the frequencies after
the test is done.

v2: Restore max freq first and then min.

Signed-off-by: Vinay Belgaumkar <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc/slpc: Provide sysfs for efficient freq

SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.

Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it through this interface.

v2: Keep just one interface to toggle sysfs. With this, user will
be completely responsible for toggling efficient frequency if need
be. There will be no implicit disabling when user sets min < RP1 (Ashutosh)

v3: Remove unused label, review comments (Ashutosh)

v4: Toggle efficient freq usage in SLPC selftest and checkpatch fixes

v5: Review comments (Andi) and add a separate patch for selftest updates

Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Signed-off-by: Vinay Belgaumkar <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Ashutosh Dixit <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915: Use correct huge page manager for MTL

MTL currently uses gen8_ppgtt_insert_huge when managing huge pages.
This is because MTL reports as not supporting 64K pages, or more
accurately, the system that reports whether a platform has 64K pages
reports false for MTL.  This is only half correct, as the 64K page support
reporting system only cares about 64K page support for LMEM, which MTL
doesn't have.

MTL should be using xehpsdv_ppgtt_insert_huge.  However, simply changing
over to using that manager doesn't resolve the issue because MTL is
expecting the virtual address space for the page table to be flushed after
initialization, so we must also add a flush statement there.

Signed-off-by: Jonathan Cavitt <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915: Migrate platform-dependent mock hugepage selftests to live

Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests
into live selftests as their requirements have recently become
platform-dependent. Additionally, apply necessary platform dependency
checks to these tests.

v8:
- handle properly 64K and 2M pages
v9:
- do not expect 64K pages if 2M are present
- fix hex printing
- obey commit message line limit

Signed-off-by: Jonathan Cavitt <[email protected]>
Co-developed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Implement Wa_14019141245

Enable strict RAR to prevent spurious GPU hangs.

v1.1: Rebase
Bspec: 51762
Cc: Rodrigo Vivi <[email protected]>
Signed-off-by: Radhakrishna Sripada <[email protected]>
Reviewed-by:Haridhar Kalvala <[email protected]>
Reviewed-by: Umesh Nerlige Ramappa <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/hwmon: Block waiting for GuC reset to complete

Instead of erroring out when GuC reset is in progress, block waiting for
GuC reset to complete which is a more reasonable uapi behavior.

v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
v3: Remove timeout when blocked (Tvrtko)

Signed-off-by: Ashutosh Dixit <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Disable PL1 power limit when loading GuC firmware

On dGfx, the PL1 power limit being enabled and set to a low value results
in a low GPU operating freq. It also negates the freq raise operation which
is done before GuC firmware load. As a result GuC firmware load can time
out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
limit was enabled and set to a low value). Therefore disable the PL1 power
limit when allowed by HW when loading GuC firmware.

v2:
 - Take mutex (to disallow writes to power1_max) across GuC reset/fw load
 - Add hwm_power_max_restore to error return code path

v3 (Jani N):
 - Add/remove explanatory comments
 - Function renames
 - Type corrections
 - Locking annotation

v4:
 - Don't hold the lock across GuC reset (Rodrigo)
 - New locking scheme (suggested by Rodrigo)
 - Eliminate rpm_get in power_max_disable/restore, not needed (Tvrtko)

v5:
 - Fix uninitialized pl1en variable compile warning reported by kernel
   build robot by creating new err_rps label

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Signed-off-by: Ashutosh Dixit <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write

In preparation for follow-on patches, refactor hwm_power_max_write to take
hwmon_lock and runtime pm wakeref at start of the function and release them
at the end, therefore acquiring these just once each.

Signed-off-by: Ashutosh Dixit <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/guc: Actually return an error if GuC version range check fails

Dan Carpenter pointed out that 'err' was not being set in the case
where the GuC firmware version range check fails. Fix that.

Note that while this is a bug fix for a previous patch (see Fixes tag
below). It is an exceedingly low risk bug. The range check is
asserting that the GuC firmware version is within spec. So it should
not be possible to ever have a firmware file that fails this check. If
larger version numbers are required in the future, that would be a
backwards breaking spec change and thus require a major version bump,
in which case an old i915 driver would not load that new version anyway.

Fixes: 9bbba0667f37 ("drm/i915/guc: Use GuC submission API version number")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: John Harrison <[email protected]>
Cc: John Harrison <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Alan Previn <[email protected]>
Cc: Umesh Nerlige Ramappa <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Matthew Brost <[email protected]>
Cc: Andi Shyti <[email protected]>
Cc: Matthew Auld <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Jani Nikula <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Add workaround 14018778641

WA 18018781329 is applicable now across all MTL
steppings.

V2:
  - Remove IS_MTL check, code already running for MTL - Matt

Cc: Matt Roper <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/selftest: Record GT error for gt failure

igt_live_test has pr_err dumped in case of some
GT failures. It will be more informative regarding
GT if we use gt_err instead.

Cc: Andi Shyti <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: workaround coherency issue for Media

This patch implements Wa_22016122933.

In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line.
This patch circumvents the issue by making CPU/GPU shared memory
uncacheable (WC on CPU side, and PAT index 2 for GPU).  Additionally,
it ensures that CPU writes are visible to the GPU with an
intel_guc_write_barrier().

While fixing the CTB issue, we noticed some random GSC firmware
loading failure because the share buffers are cacheable (WB) on CPU
side but uncached on GPU side. To fix these issues we need to map
such shared buffers as WC on CPU side. Since such allocations are
not all done through GuC allocator, to avoid too many code changes,
the i915_coherent_map_type() is now hard coded to return WC for MTL.

v2: Simplify the commit message(Matt).

BSpec: 45101

Signed-off-by: Fei Yang <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Acked-by: Nirmoy Das <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Add PTE encode function

PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.

Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS and PAT tables for MTL")
Signed-off-by: Fei Yang <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Acked-by: Nirmoy Das <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/i915_drv: Use i915 instead of dev_priv insied the file_priv structure

In the process of renaming all instances of 'dev_priv' to 'i915',
start using 'i915' within the i915_drv.h file.

Signed-off-by: Andi Shyti <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/i915_drv: Use proper parameter naming in for_each_engine()

for_each_engine() loops through engines in the GT, not in
dev_priv.  Because it's misleading, call it "gt__" instead of
"dev_priv__".

Signed-off-by: Andi Shyti <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: fix mocs selftest

Media GT has a different base for MOCS register, need to apply
gsi_offset to the mmio address if not using the intel_uncore_r/w
functions for register access.

Cc: Matt Roper <[email protected]>
Signed-off-by: Fei Yang <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Define MOCS and PAT tables for MTL

On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with programming new register bits that MTL
requires calls for a MOCS/PAT table update.
Also the PAT index registers are multicasted for primary GT,
and there is an address jump from index 7 to 8. This patch
makes sure that these registers are programmed in the proper
way.

BSpec: 44509, 45101, 44235

Cc: Matt Roper <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Signed-off-by: Madhumitha Tolakanahalli Pradeep <[email protected]>
Signed-off-by: Aravind Iddamsetty <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Signed-off-by: Fei Yang <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Set has_llc=0

On MTL, LLC is not shared between GT and CPU, set has_llc=0.

Signed-off-by: Fei Yang <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Nirmoy Das <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: WA to clear RDOP clock gating

Workaround implementation to clear RDOP clock gating.

Bspec: 66622
Signed-off-by: Haridhar Kalvala <[email protected]>
Signed-off-by: Radhakrishna Sripada <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Extend Wa_22011802037 to MTL A-step

Wa_22011802037 was being applied to all graphics_ver 11 & 12. This patch
updates the if statement to apply the W/A to right platforms and extends
it to MTL-M:A step.

v1.1: Fix checkpatch warning.
v2: Change the check to reflect the wa at other places(Lucas)

Bspec: 66622
Cc: Lucas De Marchi <[email protected]>
Cc: Umesh Nerlige Ramappa <[email protected]>
Signed-off-by: Madhumitha Tolakanahalli Pradeep <[email protected]>
Signed-off-by: Radhakrishna Sripada <[email protected]>
Reviewed-by: Matt Atwood <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/selftests: Consider multi-gt instead of to_gt()

In order to enable complete multi-GT, loop through all
the GTs, rather than relying on the to_gt(), which only
provides a reference to the primary GT.

Problem appear when it runs on platform like MTL where
different set of engines are possible on different GTs.

Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/gem: Consider multi-gt instead of to_gt()

In order to enable complete multi-GT, use the GT
reference obtained directly from the engine, rather
than relying on the to_gt(), which only provides a
reference to the primary GT.

Problem appear when it runs on platform like MTL
where different set of engines are possible on
different GTs.

Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/gt: Consider multi-gt instead of to_gt()

In order to enable complete multi-GT, use the GT
reference obtained directly from the engine, rather
than relying on the to_gt(), which only provides a
reference to the primary GT.

Problem appear when it runs on platform like MTL
where different set of engines are possible on
different GTs.

Cc: Andi Shyti <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915: Make IRQ reset and postinstall multi-gt aware

In multi-gt systems IRQs need to be reset and enabled per GT.

This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.

Signed-off-by: Andi Shyti <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915: Fix memory leaks in i915 selftests

This patch fixes memory leaks on error escapes in function fake_get_pages

Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist creation")
Signed-off-by: Cong Liu <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Signed-off-by: Andi Shyti <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/gt: Avoid out-of-bounds access when loading HuC

When HuC is loaded by GSC, there is no header definition for the kernel
to look at and firmware is just handed to GSC. However when reading the
version, it should still check the size of the blob to guarantee it's not
incurring into out-of-bounds array access.

If firmware is smaller than expected, the following message is now
printed:

# echo boom > /lib/firmware/i915/dg2_huc_gsc.bin
# dmesg | grep -i huc
[drm] GT0: HuC firmware i915/dg2_huc_gsc.bin: invalid size: 5 < 184
[drm] *ERROR* GT0: HuC firmware i915/dg2_huc_gsc.bin: fetch failed -ENODATA
...

Even without this change the size, header and signature are still
checked by GSC when loading, so this only avoids the out-of-bounds array
access.

Fixes: a7b516bd981f ("drm/i915/huc: Add fetch support for gsc-loaded HuC binary")
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Alan Previn <[email protected]>
Signed-off-by: Lucas De Marchi <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

drm/i915/mtl: Disable stolen memory backed FB for A0

Stolen memory is not usable for MTL A0 stepping beyond
certain access size and we have no control over userspace
access size of /dev/fb which can be backed by stolen memory.
So disable stolen memory backed fb by setting i915->dsm.usable_size
to zero.

v2: remove hsdes reference and fix commit message(Andi)
v3: use revid as we want to target SOC stepping(Radhakrishna)

Cc: Matthew Auld <[email protected]>
Cc: Andi Shyti <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Radhakrishna Sripada <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Reviewed-by: Andi Shyti <[email protected]>
Reviewed-by: Radhakrishna Sripada <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

Merge drm/drm-next into drm-intel-gt-next

Need to pull in commit from drm-next (earlier in drm-intel-next):

1eca0778f4b3 ("drm/i915: add struct i915_dsm to wrap dsm members together")

In order to merge following patch to drm-intel-gt-next:

https://patchwork.freedesktop.org/patch/530942/?series=114925&rev=6

Signed-off-by: Joonas Lahtinen <[email protected]>

Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next

Mediatek DRM Next for Linux 6.4

1. Add support for 10-bit overlays
2. Add MediaTek SoC DRM (vdosys1) support for mt8195
3. Change mmsys compatible for mt8195 mediatek-drm
4. Only trigger DRM HPD events if bridge is attached
5. Change the aux retries times when receiving AUX_DEFER

Signed-off-by: Daniel Vetter <[email protected]>
From: Chun-Kuang Hu <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

Merge tag 'drm-msm-next-2023-04-10' of https://gitlab.freedesktop.org/drm/msm into drm-next

main pull request for v6.4

Core Display:
============
* Bugfixes for error handling during probe
* rework UBWC decoder programming
* prepare_commit cleanup
* bindings for SM8550 (MDSS, DPU), SM8450 (DP)
* timeout calculation fixup
* atomic: use drm_crtc_next_vblank_start() instead of our own
  custom thing to calculate the start of next vblank

DP:
==
* interrupts cleanup

DPU:
===
* DSPP sub-block flush on sc7280
* support AR30 in addition to XR30 format
* Allow using REC_0 and REC_1 to handle wide (4k) RGB planes
* Split the HW catalog into individual per-SoC files

DSI:
===
* rework DSI instance ID detection on obscure platforms

GPU:
===
* uapi C++ compatibility fix
* a6xx: More robust gdsc reset
* a3xx and a4xx devfreq support
* update generated headers
* various cleanups and fixes
* GPU and GEM updates to avoid allocations which could trigger
  reclaim (shrinker) in fence signaling path
* dma-fence deadline hint support and wait-boost
* a640 speedbin support
* a650 speedbin support

Conflicts in drivers/gpu/drm/msm/adreno/adreno_gpu.c:

Conflict between the 7fa5047a436b ("drm: Use of_property_present() for
testing DT property presence") and 9f251f934012 ("drm/msm/adreno: Use
OPP for every GPU generation"). The latter removed the of_ function
call outright, so I went with what's in the PR unchanged.

From: Rob Clark <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvwuj5tabyW910+N-B=5kFNAC7QNYoQ=0xi3roBjQvFFQ@mail.gmail.com
Signed-off-by: Daniel Vetter <[email protected]>

Merge tag 'drm-habanalabs-next-2023-04-10' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next

This tag contains additional habanalabs driver changes for v6.4:

- uAPI changes:
  - Add a definition of a new Gaudi2 server type. This is used by userspace
    to know what is the connectivity between the accelerators inside the
    server

- New features and improvements:
  - speedup h/w queues test in Gaudi2 to reduce device initialization times.

- Firmware related fixes:
  - Fixes to the handshake protocol during f/w initialization.
  - Sync f/w events interrupt in hard reset to avoid warning message.
  - Improvements to extraction of the firmware version.

- Misc bug fixes and code cleanups. Notable fixes are:
  - Multiple fixes for interrupt handling in Gaudi2.
  - Unmap mapped memory in case TLB invalidation fails.

Signed-off-by: Daniel Vetter <[email protected]>
From: Oded Gabbay <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

accel/habanalabs: add missing error flow in hl_sysfs_init()

hl_sysfs_fini() is called only if hl_sysfs_init() completes
successfully. Therefore if hl_sysfs_init() fails, need to remove any
sysfs group that was added until that point.

Signed-off-by: Tomer Tayar <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: speedup h/w queues test in Gaudi2

HW queues testing at driver load and after reset takes a substantial
amount of time.
This commit reduces the queues test time in Gaudi2 devices by running
all the tests in parallel instead of one after the other.
Time measurements on tests duration shows that the new method is almost
x100 faster than the serial approach.

Signed-off-by: Moti Haimovski <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: fix handling of arc farm sei event

There is only single eq entry for arc farm sei event which aggregates
events from the four arc farms.
Fix the code to handle this event according to this behavior.

Signed-off-by: Dani Liberman <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: remove Gaudi1 multi MSI code

Multi MSI interrupts aren't working in Gaudi1 and because of that,
we are only using a single MSI interrupt. Therefore, let's remove this
dead code in order to avoid confusion.

Signed-off-by: Ofir Bitton <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs/uapi: new Gaudi2 server type

Add definition of a new Gaudi2 server type. This represents
the connectivity between the cards in that server type.

Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>

accel/habanalabs: fixes for unexpected error interrupt

Removing redundant asic prop variable as we don't need to expose this
to common code. In addition, fix some typos.

Signed-off-by: Ofir Bitton <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: don't wait for STS_OK after sending COMMS WFE

Sending COMMS_GOTO_WFE instructs the FW's CPU to halt (WFE state).
Once sent, FW's CPU isn't expected to continue communicating with LKD.
Therefore, the stage of waiting for COMMS_STS_OK should be skipped or
else waiting for COMMS_STS_OK will simply timeout, which will trigger
unexpected behavior.

Signed-off-by: Koby Elbaz <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: sync f/w events interrupt in hard reset

Receiving events from FW, while the device is in hard reset, causes
a warning message in Driver log. The message may point to a
problem in the Driver or FW. But It also can appear as a result
of events that have been sent from FW just before the hard reset.
In order to avoid receiving events from FW while the device is in reset
and is already in 'disabled' mode, sync the f/w events interrupt right
before setting the device to 'disabled'.

Signed-off-by: Tal Cohen <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: fix wrong reset and event flags

During event handling, driver sets relevant reset and user event
notifier flags. Fix few wrong flags settings.

Signed-off-by: Ofir Bitton <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: fix events mask of decoder abnormal interrupts

The decoder IRQ status register may have several set bits upon an
abnormal interrupt. Therefore, when setting the events mask, need to
check all bits and not using if-else.

Signed-off-by: Tomer Tayar <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: remove completion from abnormal interrupt work name

Decoder abnormal interrupts are for errors and not for completion, so
rename the relevant work and work function to not include 'completion'.

Signed-off-by: Tomer Tayar <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: print raw binning masks in debug level

There are rare cases of failures when cards are initialized due to
wrong values in efuse mappings that are parsed by firmware.

To help debug those cases, print (in debug level) the raw binning masks
as fetched from the firmware during device initialization.

Signed-off-by: Ofir Bitton <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: fix HBM MMU interrupt handling

Current mapping between HMMU event and HMMU block is wrong.
In addition the captured address in case of a page fault or
an access error is scrambled, Hence we must call the descramble
function.

Signed-off-by: Ofir Bitton <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: improvements to FW ver extraction

1. Rename the func to hl_get_preboot_major_minor because we also set
   the extracted values in hdev fields.

2. Free the allocated string in the calling function which makes more
   sense

Signed-off-by: Dafna Hirschfeld <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: fix access error clear event

The register which needs to be cleared is the valid register instead
of the address.

Signed-off-by: Dani Liberman <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>

accel/habanalabs: send disable pci when compute ctx is active

Fix an issue in hard reset flow in which the driver didn't send a
disable pci message if there was an active compute context.
In hard reset, disable pci message should be sent no matter if
a compute context exists or not.

Signed-off-by: Tal Cohen <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>

accel/habanalabs: remove duplicated disable pci msg

The disable pci message is sent in reset device. It informs the FW not
to raise more EQs. The Driver may ignore received EQs, when the device
is in disabled mode.
The duplication happens when hard reset is scheduled during compute
reset and also performs 'escalate_reset_flow'.

Signed-off-by: Tal Cohen <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>

accel/habanalabs: change COMMS warning messages to error level

COMMS protocol is used for LKD <--> FW communication, and any
communication failure between the two might turn out to be
destructive, hence, it should be well emphasized.

Signed-off-by: Koby Elbaz <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>

accel/habanalabs: check return value of add_va_block_locked

since the function might fail and we should propagate the failure.

Signed-off-by: Dafna Hirschfeld <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>

accel/habanalabs: print event type when device is disabled

When the device is in disabled state, the driver isn't suppose to
receive any events from FW. Printing the event type, as part of the
message that was already printed, shall help to get more info if this
unexpected message is received.

Signed-off-by: Tal Cohen <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>

accel/habanalabs: unmap mapped memory when TLB inv fails

Once a memory mapping is added to the page tables, it's followed by
a TLB invalidation request which could potentially fail (HW failure).
Removing the mapping is simply a part of this failure handling routine.
TLB invalidation failure prints were updated to be more accurate.

Signed-off-by: Koby Elbaz <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>