drm/i915/tc: un-inline intel_tc_port_ref_held()

Avoid including the intel_drv.h mega header from other header files to
make further header cleanup easier.

v2: restore the over-eagerly dropped <linux/types.h> (Imre)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190806113700.18816-1-jani.nikula@intel.com

drm/i915/mst: un-inline intel_dp_mst_encoder_active_links()

Avoid including the intel_drv.h mega header from other header files to
make further header cleanup easier.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ae8f7a9514a9e952e1e0dba411aeb42293d1e183.1565085691.git.jani.nikula@intel.com

drm/i915/bw: make intel_atomic_get_bw_state() static

No need for this function to be accessible outside of intel_bw.c. Avoid
including the i915_drv.h mega header from other header files to make
further header cleanup easier.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6c898ec6511af47c1c5b679e516dc757cd207146.1565085691.git.jani.nikula@intel.com

drm/i915/irq: un-inline functions to avoid i915_drv.h include

Avoid including the i915_drv.h mega header from other header files to
make further header cleanup easier.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/45431103f6cbd4322808907154336fdc176ff20d.1565085691.git.jani.nikula@intel.com

drm/i915/sprite: un-inline icl_is_hdr_plane()

Avoid including the i915_drv.h mega header from other header files to
make further header cleanup easier.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5f998c72018c0f1cc5cdb239327a1281d21f4c0e.1565085691.git.jani.nikula@intel.com

drm/i915: move intel_display.c function declarations

Move the declarations of functions in intel_display.c to
intel_display.h. There is still plenty of cleanup to do in
intel_display.[ch], but one step at a time.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ebe19d3c508faa82e651ab3c8eb7a0975bfa52b7.1565085691.git.jani.nikula@intel.com

drm/i915/dmc: Load DMC on TGL

Add Support to load DMC v2.03 on TGL.

v2: Use version 2.03 that is already available since that works with
    PSR2

Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802183856.27280-1-lucas.demarchi@intel.com

drm/i915/gt: Move the [class][inst] lookup for engines onto the GT

To maintain a fast lookup from a GT centric irq handler, we want the
engine lookup tables on the intel_gt. To avoid having multiple copies of
the same multi-dimension lookup table, move the generic user engine
lookup into an rbtree (for fast and flexible indexing).

v2: Split uabi_instance cf uabi_class
v3: Set uabi_class/uabi_instance after collating all engines to provide a
stable uabi across parallel unordered construction.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20190806124300.24945-2-chris@chris-wilson.co.uk

drm/i915/gem: Make caps.scheduler static

We do not notify userspace when the scheduler capabilities are changed
(due to wedging the driver) and as such userspace will expect the caps
to be static and unchanging. Make it so, and so we only need to compute
our caps once during driver registration.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190806124300.24945-1-chris@chris-wilson.co.uk

drm/i915: Use drm_i915_private directly from drv_get_drvdata()

As we store a pointer to i915 in the drvdata field (as the pointer is both
an alias to the drm_device and drm_i915_private), we can use the stored
pointer directly as the i915 device.

v2: Store and use i915 inside drv_get_drvdata()
v3: Only expect i915 inside drv_get_drvdata() so drop the assumed
i915/drm equivalence.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190806074219.11043-1-chris@chris-wilson.co.uk

drm/i915/gt: Remove stale kerneldoc for internal MOCS functions

The kerneldoc were stale, generating mismatching parameters warning, but
furthermore they were for internal routines, not part of the MOCS
interface so the instructions were superfluous.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190803102221.21344-1-chris@chris-wilson.co.uk

drm/i915/uc: Don't fail on HuC early init errors

Since commit 301efe96f777 ("drm/i915/uc: Don't fail on HuC
firmware failure") we can continue driver load after error
during HuC firmware load or authentication, but we could
still fail on any error during early HuC initialization.
Change that by ignoring HuC related errors until hardware
initialization phase where we can decide about next steps.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-5-michal.wajdeczko@intel.com

drm/i915/uc: Remove redundant GuC support checks

Since commit db81bc6eb9c0 ("drm/i915/uc: Consider enable_guc
modparam during fw selection") we have started using firmware
status as main indicator of the GuC support. No need to use
same checks twice.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-4-michal.wajdeczko@intel.com

drm/i915/huc: Prefer intel_huc_is_supported

No need to dance with intel_uc_supports_huc(uc) as we
can directly use intel_huc_is_supported(huc)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-3-michal.wajdeczko@intel.com

drm/i915/guc: Prefer intel_guc_is_submission_supported

No need to use intel_uc_supports_guc_submission(uc) as we
can directly use intel_guc_is_submission_supported(guc)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-2-michal.wajdeczko@intel.com

drm/i915: Fix wrong escape clock divisor init for GLK

According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.

Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.

v2: Added Fixes tag and cc
v3: Added stable to cc as well.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M <m.deepak@intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com

drm/i915: Replace struct_mutex for batch pool serialisation

Switch to tracking activity via i915_active on individual nodes, only
keeping a list of retired objects in the cache, and reaping the cache
when the engine itself idles.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-2-chris@chris-wilson.co.uk

drm/i915: Teach execbuffer to take the engine wakeref not GT

In the next patch, we would like to couple into the engine wakeref to
free the batch pool on idling. The caveat here is that we therefore want
to track the engine wakeref more precisely and to hold it instead of the
broader GT wakeref as we process the ioctl.

v2: Avoid introducing odd semantics for a shortlived timeline->mutex
acquisition interface.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-1-chris@chris-wilson.co.uk

drm/i915: Flush the freed object list on file close

As we increase the number of RCU objects, it becomes easier for us to
have several hundred thousand objects in the deferred RCU free queues.
An example is gem_ctx_create/files which continually creates active
contexts, which are not immediately freed upon close as they are kept
alive by outstanding requests. This lack of backpressure allows the
context objects to persist until they overwhelm and starve the system.
We can increase our backpressure by flushing the freed object queue upon
closing the device fd which should then not impact other clients.

Testcase: igt/gem_ctx_create/*files
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-2-chris@chris-wilson.co.uk

drm/i915: Hide unshrinkable context objects from the shrinker

The shrinker cannot touch objects used by the contexts (logical state
and ring). Currently we mark those as "pin_global" to let the shrinker
skip over them, however, if we remove them from the shrinker lists
entirely, we don't event have to include them in our shrink accounting.

By keeping the unshrinkable objects in our shrinker tracking, we report
a large number of objects available to be shrunk, and leave the shrinker
deeply unsatisfied when we fail to reclaim those. The shrinker will
persist in trying to reclaim the unavailable objects, forcing the system
into a livelock (not even hitting the dread oomkiller).

v2: Extend unshrinkable protection for perma-pinned scratch and guc
allocations (Tvrtko)
v3: Notice that we should be pinned when marking unshrinkable and so the
link cannot be empty; merge duplicate paths.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-1-chris@chris-wilson.co.uk

drm/i915/wopcm: Don't fail on WOPCM partitioning failure

We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.

v3: rebased

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-7-michal.wajdeczko@intel.com

drm/i915/uc: Inject probe errors into intel_uc_init_hw

Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.

To avoid complains from CI about injected errors use
i915_probe_error to lower message level.

v4: rebased after moving hot fixes moved to separate patches

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-6-michal.wajdeczko@intel.com

drm/i915/uc: Move GuC error log to uc and release it on fini

When we fail to load GuC and want to abort probe, we hit:

<7> [229.915779] i915 0000:00:02.0: [drm:intel_uc_init_hw [i915]] GuC initialization failed -6
<7> [229.915813] i915 0000:00:02.0: [drm:i915_gem_init_hw [i915]] Enabling uc failed (-6)
<4> [229.953354] ------------[ cut here ]------------
<4> [229.953355] WARN_ON(dev_priv->mm.shrink_count)
<4> [229.953406] WARNING: CPU: 9 PID: 3287 at drivers/gpu/drm/i915/i915_gem.c:1684 i915_gem_cleanup_early+0xfc/0x110 [i915]
<4> [229.953464] Call Trace:
<4> [229.953489]  i915_driver_late_release+0x19/0x60 [i915]
<4> [229.953514]  i915_driver_probe+0xb82/0x18a0 [i915]
<4> [229.953519]  ? __pm_runtime_resume+0x4f/0x80
<4> [229.953545]  i915_pci_probe+0x43/0x1b0 [i915]
...
<4> [229.962951] ------------[ cut here ]------------
<4> [229.962956] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
<4> [229.962959] WARNING: CPU: 8 PID: 2395 at kernel/locking/mutex.c:912 __mutex_lock+0x750/0x9b0
<4> [229.963091] Call Trace:
<4> [229.963129]  ? i915_vma_destroy+0x86/0x350 [i915]
<4> [229.963166]  ? i915_vma_destroy+0x86/0x350 [i915]
<4> [229.963201]  i915_vma_destroy+0x86/0x350 [i915]
<4> [229.963236]  __i915_gem_free_objects+0xb8/0x510 [i915]
<4> [229.963270]  __i915_gem_free_work+0x5a/0x90 [i915]
<4> [229.963275]  process_one_work+0x245/0x610

as since commit 6f76098fe0f3 ("drm/i915/uc: Move uC early functions
inside the GT ones") we cleanup uc after gem.

Move captured GuC load error log to uc struct and release it
in intel_uc_fini() instead of intel_uc_driver_late_release()

Note that intel_uc_driver_late_release() is now empty, but
we can leave it as a placeholder for future code.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-5-michal.wajdeczko@intel.com

drm/i915/uc: Reorder firmware status codes

On Gen9 when we try to reload HuC due to GuC upload error, we hit:

<7> [232.025927] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s)
<7> [232.026004] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin
<7> [232.026686] [drm:intel_uc_fw_upload [i915]] HuC fw xfer completed
<6> [232.026688] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
<3> [232.026703] intel_uc_fw_copy_rsa:541 GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw))

as firmware that previously failed to load was wrongly treated as
unavailable since its status code was not matching status check logic.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-4-michal.wajdeczko@intel.com

drm/i915/uc: Do full sanitize instead of pure reset

On Gen9 when we try to reload HuC due to GuC upload error, we hit:

<7> [229.656688] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s)
<7> [229.656739] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin
<3> [229.656740] intel_uc_fw_upload:425 GEM_BUG_ON(intel_uc_fw_is_loaded(uc_fw))

as we performed only pure reset and didn't sanitized HuC fw status.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-3-michal.wajdeczko@intel.com

drm/i915: Add i915 to i915_inject_probe_failure

With i915 added to i915_inject_probe_failure we can use dedicated
printk when injecting artificial load failure.

Also make this function look like other i915 functions that return
error code and make it more flexible to return any provided error
code instead of previously assumed -ENODEV.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-2-michal.wajdeczko@intel.com

drm/i915: Report resv_obj allocation failure

Since commit 64d6c500a384 ("drm/i915: Generalise GPU activity
tracking"), we have been prepared for i915_vma_move_to_active() to fail.
We can take advantage of this to report the failure for allocating the
shared-fence slot in the reservation_object.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730205805.3733-1-chris@chris-wilson.co.uk

drm/i915: Fix documentation for __intel_wait_for_register_fw*

Use section name "Return" and proper error code -ETIMEDOUT

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802124739.12548-1-michal.wajdeczko@intel.com

drm/i915/oa: update the generated files

Update the generated files to make the headers self-contained, switch to
the kernel preferred SPDX comment format, and update the copyright
year. Also add the Makefile stanza to run header tests on the files.

Other changes produced by gputop i915-perf-kernelgen.py were manually
stripped out, and left to the folks who actually know something about
the OA stuff.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730113432.22146-3-jani.nikula@intel.com

drm/i915: Allow sharing the idle-barrier from other kernel requests

By placing our idle-barriers in the i915_active fence tree, we expose
those for reuse by other components that are issuing requests along the
kernel_context. Reusing the proto-barrier active_node is perfectly fine
as the new request implies a context-switch, and so an opportune point
to run the idle-barrier. However, the proto-barrier is not equivalent
to a normal active_node and care must be taken to avoid dereferencing the
ERR_PTR used as its request marker.

v2: Comment the more egregious cheek
v3: A glossary!

Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: ce476c80b8bf ("drm/i915: Keep contexts pinned until after the next kernel context switch")
Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190802100015.1281-1-chris@chris-wilson.co.uk

drm/i915: Flush extra hard after writing relocations through the GTT

Recently discovered in commit bdae33b8b82b ("drm/i915: Use maximum write
flush for pwrite_gtt") was that we needed to our full write barrier
before changing the GGTT PTE to ensure that our indirect writes through
the GTT landed before the PTE changed (and the writes end up in a
different page). That also applies to our GGTT relocation path.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730112151.5633-4-chris@chris-wilson.co.uk

drm/i915/pmu: Atomically acquire the gt_pm wakeref

Currently, we only sample if the intel_gt is awake, but we acquire our
own runtime_pm wakeref. Since intel_gt has transitioned to tracking its
own wakeref, we can atomically test and acquire that wakeref instead.

v2: Take engine->wakeref for engine sampling

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801233616.23007-1-chris@chris-wilson.co.uk

drm/i915/pmu: Make get_rc6 take intel_gt

RC6 is a GT state so make the function parameter reflect that.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-4-tvrtko.ursulin@linux.intel.com

drm/i915/pmu: Convert sampling to gt

Engines and frequencies are a GT thing so adjust sampling routines to
match.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-3-tvrtko.ursulin@linux.intel.com

drm/i915/pmu: Convert engine sampling to uncore mmio

Drops one macro using implicit dev_priv.

v2:
 * Use ENGINE_READ_FW. (Chris)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-2-tvrtko.ursulin@linux.intel.com

drm/i915/pmu: Make more struct i915_pmu centric

Just tidy the code a bit by removing a sea of overly verbose i915->pmu.*.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-1-tvrtko.ursulin@linux.intel.com

drm/i915/tgl: allow the reg_read ioctl to read the RCS TIMESTAMP register

This enables the Mesa driver to advertise support for ARB_timer_query,
and thus an OpenGL version higher than 3.2.

Based on the ICL patch by Paulo Zanoni and CNL patch by Nanley Chery.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-3-lucas.demarchi@intel.com

drm/i915/tgl: Add and use new DC5 and DC6 residency counter registers

Tiger Lake has a new register offset for DC5 and DC6 residency counters.

v2:
  - Rename registers since they are not in the CSR memory range
    (requested by Anshuman)
  - Fix type (requested by Matthew)

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-2-lucas.demarchi@intel.com

drm/i915/uc: Stop sanitizing enable_guc modparam

As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.

v2: rebased, reworded info messages
v3: oops

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801132840.33176-1-michal.wajdeczko@intel.com

drm/i915/guc: Use dedicated flag to track submission mode

Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.

v2: rebased, simplified condition (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-4-michal.wajdeczko@intel.com

drm/i915/uc: Consider enable_guc modparam during fw selection

We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.

v2: rebased, don't care about <0 (Chris)
v3: oops

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-3-michal.wajdeczko@intel.com

drm/i915/uc: Rename intel_uc_is_using* into intel_uc_supports*

Rename intel_uc_is_using* into intel_uc_supports* to make clear
distinction from actual state (compare intel_uc_fw_is_running)

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-2-michal.wajdeczko@intel.com

drm/i915/gt: Introduce intel_gt_runtime_suspend/resume

To be called from the top level runtime functions, to hide the
gt-specific bits (mainly related to intel_uc).

v2: rebased

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801005709.34092-3-daniele.ceraolospurio@intel.com

drm/i915/uc: Move uC early functions inside the GT ones

uC is a subcomponent of GT, so initialize/clean it as part of it. The
wopcm_init_early doesn't have to be happen before the uC one, but since
in other parts of the code we consider WOPCM first do the same for
consistency.

v2: s/cleanup_early/late_release to match the caller
v3: s/late_release/driver_late_release/ (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801005709.34092-2-daniele.ceraolospurio@intel.com

drm/i915/gt: Move gt_cleanup_early out of gem_cleanup_early

We don't call the init_early function from within the gem code, so we
shouldn't do it for the cleanup either.

v2: while at it, s/gt_cleanup_early/gt_late_release (Chris)
v3: s/late_release/driver_late_release/ (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801005709.34092-1-daniele.ceraolospurio@intel.com

drm/i915: Remove lrc default desc from GEM context

We only compute the lrc_descriptor() on pinning the context, i.e.
infrequently, so we do not benefit from storing the template as the
addressing mode is also fixed for the lifetime of the intel_context.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730133035.1977-9-chris@chris-wilson.co.uk

drm/i915/ehl: Don't forget to handle port C's hotplug interrupts

We're mostly re-using ICL's interrupt handling on EHL, but we still need
to remember to account for the extra combo port that EHL has.  Use TGP's
mask (which includes combo port C) rather than ICP's mask when
appropriate.  Let's also skip reading TC-specific registers on this
platform since EHL doesn't have any TC ports.

v2: Base setup of SHOTPLUG_CTL_TC on whether the tc pin mask is non-zero
    rather than performing another PCH type check.  (Jose)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730220553.15300-1-matthew.d.roper@intel.com

drm/i915/oa: add content to Makefile

Apparently the empty Makefile has caused some confusion. Add the
subdir-cc-flags-y as in 7fcc7ca549d4 ("drm/i915: add header search path
to subdir Makefiles") which should be useful.

The generated headers still aren't self-contained, so can't add that.

References: http://marc.info/?i=80bf2204-558a-6d3f-c493-bf17b891fc8a@infradead.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730113432.22146-1-jani.nikula@intel.com

drm/i915: fix possible memory leak in intel_hdcp_auth_downstream()

'ksv_fifo' is malloced in intel_hdcp_auth_downstream() and should be
freed before leaving from the error handling cases, otherwise it will
cause memory leak.

Fixes: f26ae6a652f2 ("drm/i915: SRM revocation check for HDCP1.4 and 2.2")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190704104534.12508-1-weiyongjun1@huawei.com

drm/i915/execlists: Always clear pending&inflight requests on reset

If we skip the reset as we found the engine inactive at the time of the
reset, we still need to clear the residual inflight & pending request
bookkeeping to reflect the current state of HW.

Otherwise, we may end up stuck in a loop like:

<7> [416.490346] hangcheck rcs0
<7> [416.490371] hangcheck  Awake? 1
<7> [416.490376] hangcheck  Hangcheck: 8003 ms ago
<7> [416.490380] hangcheck  Reset count: 0 (global 0)
<7> [416.490383] hangcheck  Requests:
<7> [416.491210] hangcheck  RING_START: 0x0017b000
<7> [416.491983] hangcheck  RING_HEAD:  0x00000048
<7> [416.491992] hangcheck  RING_TAIL:  0x00000048
<7> [416.492006] hangcheck  RING_CTL:   0x00000000
<7> [416.492037] hangcheck  RING_MODE:  0x00000200 [idle]
<7> [416.492044] hangcheck  RING_IMR: 00000000
<7> [416.492809] hangcheck  ACTHD:  0x00000000_9ca00048
<7> [416.492824] hangcheck  BBADDR: 0x00000000_00001004
<7> [416.492838] hangcheck  DMA_FADDR: 0x00000000_00000000
<7> [416.492845] hangcheck  IPEIR: 0x00000000
<7> [416.492852] hangcheck  IPEHR: 0x00000000
<7> [416.492863] hangcheck  Execlist status: 0x00018001 00000000, entries 12
<7> [416.492869] hangcheck  Execlist CSB read 1, write 1, tasklet queued? no (enabled)
<7> [416.492938] hangcheck  Pending[0] ring:{start:0017b000, hwsp:fedf9000, seqno:00016fd6}, rq:  20ffa:16fd6!+  prio=-4094 @ 8307ms: signaled
<7> [416.492972] hangcheck  Queue priority hint: -4093
<7> [416.492979] hangcheck  Q  20ffa:16fd8-  prio=-4093 @ 8307ms: [i915]
<7> [416.492985] hangcheck  Q  20ffa:16fda  prio=-4094 @ 8307ms: [i915]
<7> [416.492990] hangcheck  Q  20ffa:16fdc  prio=-4094 @ 8307ms: [i915]
<7> [416.492996] hangcheck  Q  20ffa:16fde  prio=-4094 @ 8307ms: [i915]
<7> [416.493001] hangcheck  Q  20ffa:16fe0  prio=-4094 @ 8307ms: [i915]
<7> [416.493007] hangcheck  Q  20ffa:16fe2  prio=-4094 @ 8307ms: [i915]
<7> [416.493013] hangcheck  Q  20ffa:16fe4  prio=-4094 @ 8307ms: [i915]
<7> [416.493021] hangcheck  ...skipping 21 queued requests...
<7> [416.493027] hangcheck  Q  20ffa:17010  prio=-4094 @ 8307ms: [i915]
<7> [416.493081] hangcheck HWSP:
<7> [416.493089] hangcheck [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [416.493094] hangcheck *
<7> [416.493100] hangcheck [0040] 10008002 00000000 10000018 00000000 10000018 00000000 10000001 00000000
<7> [416.493106] hangcheck [0060] 10000018 00000000 10000001 00000000 10000018 00000000 10000001 00000000
<7> [416.493111] hangcheck *
<7> [416.493117] hangcheck [00a0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
<7> [416.493123] hangcheck [00c0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [416.493127] hangcheck *
<7> [416.493132] hangcheck Idle? no
<6> [416.512124] i915 0000:00:02.0: GPU HANG: ecode 11:0:0x00000000, hang on rcs0
<6> [416.512205] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
<6> [416.512207] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
<6> [416.512208] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
<6> [416.512210] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
<6> [416.512212] [drm] GPU crash dump saved to /sys/class/drm/card0/error
<5> [416.513602] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
<7> [424.489258] hangcheck rcs0
<7> [424.489263] hangcheck  Awake? 1
<7> [424.489267] hangcheck  Hangcheck: 5954 ms ago
<7> [424.489271] hangcheck  Reset count: 1 (global 0)
<7> [424.489274] hangcheck  Requests:
<7> [424.490128] hangcheck  RING_START: 0x00000000
<7> [424.490870] hangcheck  RING_HEAD:  0x00000000
<7> [424.490877] hangcheck  RING_TAIL:  0x00000000
<7> [424.490887] hangcheck  RING_CTL:   0x00000000
<7> [424.490897] hangcheck  RING_MODE:  0x00000200 [idle]
<7> [424.490904] hangcheck  RING_IMR: 00000000
<7> [424.490917] hangcheck  ACTHD:  0x00000000_00000000
<7> [424.490930] hangcheck  BBADDR: 0x00000000_00000000
<7> [424.490943] hangcheck  DMA_FADDR: 0x00000000_00000000
<7> [424.490950] hangcheck  IPEIR: 0x00000000
<7> [424.490956] hangcheck  IPEHR: 0x00000000
<7> [424.490968] hangcheck  Execlist status: 0x00000001 00000000, entries 12
<7> [424.490972] hangcheck  Execlist CSB read 11, write 11, tasklet queued? no (enabled)
<7> [424.490983] hangcheck  Pending[0] ring:{start:0017b000, hwsp:fedf9000, seqno:00016fd6}, rq:  20ffa:16fd6!+  prio=-4094 @ 16305ms: signaled
<7> [424.490989] hangcheck  Queue priority hint: -4093
<7> [424.490996] hangcheck  Q  20ffa:16fd8-  prio=-4093 @ 16305ms: [i915]
<7> [424.491001] hangcheck  Q  20ffa:16fda  prio=-4094 @ 16305ms: [i915]
<7> [424.491006] hangcheck  Q  20ffa:16fdc  prio=-4094 @ 16305ms: [i915]
<7> [424.491011] hangcheck  Q  20ffa:16fde  prio=-4094 @ 16305ms: [i915]
<7> [424.491016] hangcheck  Q  20ffa:16fe0  prio=-4094 @ 16305ms: [i915]
<7> [424.491022] hangcheck  Q  20ffa:16fe2  prio=-4094 @ 16305ms: [i915]
<7> [424.491048] hangcheck  Q  20ffa:16fe4  prio=-4094 @ 16305ms: [i915]
<7> [424.491057] hangcheck  ...skipping 21 queued requests...
<7> [424.491063] hangcheck  Q  20ffa:17010  prio=-4094 @ 16305ms: [i915]
<7> [424.491095] hangcheck HWSP:
<7> [424.491102] hangcheck [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [424.491106] hangcheck *
<7> [424.491113] hangcheck [0040] 10008002 00000000 10000018 00000000 10000018 00000000 10000001 00000000
<7> [424.491118] hangcheck [0060] 10000018 00000000 10000001 00000000 10000018 00000000 10000001 00000000
<7> [424.491122] hangcheck *
<7> [424.491127] hangcheck [00a0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000b
<7> [424.491133] hangcheck [00c0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [424.491136] hangcheck *
<7> [424.491141] hangcheck Idle? no
<5> [424.491834] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0

Where not having cleared the pending array on reset, it persists
indefinitely.

Fixes: fff8102aaed5 ("drm/i915/execlists: Process interrupted context on reset")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730133035.1977-2-chris@chris-wilson.co.uk

drm/i915/ehl: Ungate DDIC and DDID

Specification states that DDI_CLK_SEL needs to be mapped to MG clock
even if MG do not exist on EHL, this will ungate those DDIs.

BSpec: 20845
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730175121.16413-1-jose.souza@intel.com

drm/i915: Move MOCS setup to intel_mocs.c

Hide the details of MOCS setup from i915_gem by moving both current calls
into one in intel_mocs_init.

Cc: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-21-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-6-lucas.demarchi@intel.com

drm/i915/tgl: Tigerlake only has global MOCS registers

Until Icelake, each engine had its own set of 64 MOCS registers. In
order to simplify, Tigerlake moves to only 64 Global MOCS registers,
which are no longer part of the engine context. Since these registers
are now global, they also only need to be initialized once.

>From Gen12 onwards, MOCS must specify the target cache (3:2) and LRU
management (5:4) fields and cannot be programmed to 'use the value from
Private PAT', because these fields are no longer part of the PPAT. Also
cacheability control (1:0) field has changed, 00 no longer means 'use
controls from page table', but uncacheable (UC).

v2 (Lucas):
    - Move the changes to the fault registers to a separate commit - the
      old ones overlap with the range used by the new global MOCS
      (requested by Daniele)
v3 (Lucas):
    - Clarify comment about setting the unused entries to the same value
      of index 0, that is the invalid entry (requested by Daniele)
    - Move changes to DONE_REG and ERROR_GEN6 to a separate commit
      (requested by Daniele)

Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-5-lucas.demarchi@intel.com

drm/i915/tgl: Define MOCS entries for Tigerlake

The MOCS table is published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.

Two of the 3 legacy entries used for gen9 are no longer expected to work.
Although we are changing the gen11 table, those changes are supposed to
be backward compatible since we are only touching previously undefined
entries.

v2: Add the missing entries in 49-51 range and replace "HW reserved"
    terminology to what it actually is: L1 is implicitly enabled
    (from Daniele)
v3: Use a different table for Tiger Lake since entries 0 and 1 are not
    the same (from Daniele)

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-4-lucas.demarchi@intel.com

drm/i915/tgl: stop using ERROR_GEN6 and DONE_REG

These registers have been removed on gen12.

v2: merge common branch for IS_GEN_RANGE(i915, 6, 11)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-3-lucas.demarchi@intel.com

drm/i915/tgl: Move fault registers to their new offset

The fault registers moved to another offset. The old location is now
taken by the global MOCS registers, to be added in a follow up change.

Based on previous patches by Michel Thierry <michel.thierry@intel.com>.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-2-lucas.demarchi@intel.com

drm/i915: remove dangling forward declaration

Commit 20a7f2fc4d7a ("drm/i915: Convert intel_mocs_init_l3cc_table to
intel_gt") removed the only user.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730182614.14379-1-lucas.demarchi@intel.com

drm/i915/uc: Move uC WOPCM setup in uc_init_hw

The register we write are not WOPCM regs but uC ones related to how
GuC and HuC are going to use the WOPCM, so it makes logical sense
for them to be programmed as part of uc_init_hw. The WOPCM map on the
other side is not uC-specific (although that is our main use-case), so
keep that separate.

v2: move write_and_verify to uncore, fix log, re-use err_out tag,
    add intel_wopcm_guc_base, fix log

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730230743.19542-2-daniele.ceraolospurio@intel.com

drm/i915/uc: Don't enable communication twice on resume

When coming out of S3/S4 we sanitize and re-init the HW, which includes
enabling communication during uc_init_hw. We therefore don't want to do
that again in uc_resume and can just tell GuC to reload its state.

v2: split uc_resume and uc_runtime_resume to match the suspend
    functions and to better differentiate the expected state in the 2
    scenarios (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730230743.19542-1-daniele.ceraolospurio@intel.com

drm/i915/selftests: Pass intel_context to igt_spinner

Teach igt_spinner to only use our internal structs, decoupling the
interface from the GEM contexts. This makes it easier to avoid
requiring ce->gem_context back references for kernel_context that may
have them in future.

v2: Lift engine lock to verify_wa() caller.
v3: Less than v2, but more so

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190731081126.9139-1-chris@chris-wilson.co.uk

drm/i915: Avoid ce->gem_context->i915

My plan for the future is to have kernel contexts not to have a GEM
context backpointer (as they will not belong to any GEM context). In a
few places, we use ce->gem_context to simply obtain the i915 backpointer,
for which we can use ce->engine->i915 instead.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730163441.16477-1-chris@chris-wilson.co.uk

drm/i915: make i915_selftest.h self-contained

Fix build breakage:

In file included from <command-line>:
./drivers/gpu/drm/i915/i915_selftest.h:125:1: error: unknown type name ‘bool’
  125 | bool __igt_timeout(unsigned long timeout, const char *fmt, ...);
      | ^~~~

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730181759.26162-1-lucas.demarchi@intel.com

drm/i915/tgl: handle DP aux interrupts

For Tiger Lake the DE Port Interrupt Definition bits changed, so use the
new bit definitions.

Cc: Jose Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-7-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-4-lucas.demarchi@intel.com

drm/i915/tgl: Update north display hotplug detection to TGL connections

TGL has 3 combophys and 6 TC/TBT ports, so it has 2 more TC/TBT ports
than ICL and the PORT_C on TGL is a combophy.
So here adding a new hpd north table and function to detect long
pulse for TGL.

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-6-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-3-lucas.demarchi@intel.com

drm/i915/tgl: Add hpd interrupt handling

Add hotdplug detection for all ports on TGP. icp_hpd_detection_setup()
is refactored to be shared with TGP.

While we increase the number of pins, add a BUILD_BUG_ON() to avoid
going over the number of bits allowed.

v2: use BITS_PER_TYPE and correct type for BUILD_BUG_ON() check
    (requested by Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jose Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-2-lucas.demarchi@intel.com

drm/i915: Update DRIVER_DATE to 20190730

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/gt: Provide a local intel_context.vm

Track the currently bound address space used by the HW context. Minor
conversions to use the local intel_context.vm are made, leaving behind
some more surgery required to make intel_context the primary through the
selftests.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730143209.4549-2-chris@chris-wilson.co.uk

drm/i915: Move aliasing_ppgtt underneath its i915_ggtt

The aliasing_ppgtt provides a PIN_USER alias for the global gtt, so move
it under the i915_ggtt to simplify later transformations to enable
intel_context.vm.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730143209.4549-1-chris@chris-wilson.co.uk

drm/i915: Inline engine->init_context into its caller

We only use the init_context vfunc once while recording the default
context state, and we use the same sequence in each backend (eliding
steps that do not apply). Remove the vfunc for simplicity and
de-duplication.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190729113720.24830-1-chris@chris-wilson.co.uk

drm/i915: use upstream version of header tests

Throw out our local hacks of header tests now that the more generic
kbuild versions are upstream.

At least for now, continue to keep the header tests behind
CONFIG_DRM_I915_WERROR=y knob.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190729140847.18557-1-jani.nikula@intel.com

drm/i915/uc: Don't fail on HuC firmware failure

HuC is usually not a critical component, so we can safely ignore
firmware load or authentication failures unless HuC was explicitly
requested by the user.

v2: add convenient way to disable loading (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190729112612.37476-1-michal.wajdeczko@intel.com

Merge drm/drm-next into drm-intel-next-queued

Catching up with 5.3-rc*

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Flush the i915_vm_release before ggtt shutdown

As the gen6_ppgtt may refer back to the GGTT for their page-directory
slots, make sure those __i915_vm_release are completed prior to shutting
down the GGTT.

Fixes: b32fa8111563 ("drm/i915/gtt: Defer address space cleanup to an RCU worker")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190729132412.23380-1-chris@chris-wilson.co.uk

drm/i915/selftests: Careful not to flush hang_fini on error setups

Smatch spotted that we test at the start of hang_fini for a valid (h->gt
is only set after a request is created) but then used it regardless
later on.

v2: Alternatively, we do not need to check as we now always prime h->gt
in hang_init()

References: cb823ed9915b ("drm/i915/gt: Use intel_gt as the primary object for handling resets")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190729085944.2179-1-chris@chris-wilson.co.uk

drm/i915/uc: Fixup kerneldoc after params were flipped and renamed

drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:194: warning: Function parameter or member 'i915' not described in 'intel_uc_fw_fetch'
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:194: warning: Excess function parameter 'dev_priv' description in 'intel_uc_fw_fetch'

Fixes: 97dee74bb34a ("drm/i915/uc: Reorder params in intel_uc_fw_fetch")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190727101055.5300-1-chris@chris-wilson.co.uk

drm/i915/tgl: update ddi/tc clock_off bits

In GEN 12 PORT_C DDI clk_off bit is not equally distanced to A/B,
it's at offset 24. Similarly TC port (5/6) clk off bits are at
offset 22/23. Extend the macros to cover the additional ports.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-4-lucas.demarchi@intel.com

drm/i915/tgl: select correct bit for port select

Bit definitions for port-select got changed for TRANS_CLK_SEL &
TRANS_DDI_FUNC_CTL registers in TGL.

v2 (Lucas):
  - Nuke TRANS_DDI_PORT_NONE since it's 0: we are already clearing
    {TGL_,}TRANS_DDI_PORT_MASK (suggested by Ville)
  - Also cover haswell_get_ddi_port_state() in intel_display.c that was
    missing
  - Define macros using the _SHIFT macros so we don't lose other users

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-3-lucas.demarchi@intel.com

drm/i915/tgl: skip setting PORT_CL_DW12_* on initialization

According to the spec when initializing the display in TGL we should not
set PORT_CL_DW12 for the Aux channel of the combo PHYs. We will re-use the
power well hooks from ICL so only set this register on gen < 12.

v2: Generalize check for gen 12 (suggested by José)
v3: Rebase after enum phy introduction

Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-2-lucas.demarchi@intel.com

drm/i915/uc: Remove redundant RSA offset definition

According to Firmware layout definition, RSA signature is located
after CSS header and uCode so actual RSA offset in the blob can be
easily calculated when needed (and we need it only once).

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190726184212.1836-3-michal.wajdeczko@intel.com

drm/i915/uc: Remove redundant ucode offset definition

According to Firmware layout definition, uCode is located right
after CSS header, so ucode offset is always same as header size.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190726184212.1836-2-michal.wajdeczko@intel.com

drm/i915/uc: Remove redundant header_offset/size definitions

According to Firmware layout definition, CSS header is located
in front of the firmware blob, so header offset is always 0.
Similarly, size of the CSS header is constant and currently
used version is exactly 128.

While here, move type/status enums up and keep them together.

v2: use sizeof consistently (Daniele), update commit message

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190726184212.1836-1-michal.wajdeczko@intel.com

drm/i915/gt: Add to timeline requires the timeline mutex

Modifying a remote context requires careful serialisation with requests
on that context, and that serialisation requires us to take their
timeline->mutex. Make it so.

Note that while struct_mutex rules, we can't create more than one
request in parallel, but that age is soon coming to an end.

v2: Though it doesn't affect the current users, contexts may share
timelines so check if we already hold the right mutex.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725131447.27515-1-chris@chris-wilson.co.uk

drm/i915/uc: Don't sanitize guc_log_level modparam

We are already storing runtime value of log level in private
field, so there is no need to modify modparam.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725205106.36148-1-michal.wajdeczko@intel.com

drm/i915: Do not rely on for loop caching the mask

for_each_engine_masked caches the engine mask but what does the caller
know.

Cache it explicitly for clarity and while at it correct the type to match.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725125056.11942-1-tvrtko.ursulin@linux.intel.com

drm/i915/perf: Initialise err to 0 before looping over ce->engines

Smatch warning that the loop may be empty causing us to check err before
it had been set. Ensure that it is initialised to 0, just in case.

v2: Refactor the inner loop for better scooping and clarity

Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190726131458.8310-1-chris@chris-wilson.co.uk

drm/i915/guc: init submission structures as part of guc_init

guc->stage_desc_pool is required as part of the init parameters and
there is no reason we have to init them after HuC. This fixes a NULL
ptr dereference due to guc->stage_desc_pool not being set (no fixes
tag since GuC submission can't be enabled yet).

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725174655.24382-1-daniele.ceraolospurio@intel.com

drm/i915/uc: Reorder params in intel_uc_fw_fetch

All intel_uc_fw_* functions are taking uc_fw as first param
except intel_uc_fw_fetch() which is taking i915. Fix that.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725210314.21188-1-michal.wajdeczko@intel.com

drm/i915: Capture vma contents outside of spinlock

Currently we use the engine->active.lock to ensure that the request is
not retired as we capture the data. However, we only need to ensure that
the vma are not removed prior to use acquiring their contents, and
since we have already relinquished our stop-machine protection, we
assume that the user will not be overwriting the contents before we are
able to record them.

In order to capture the vma outside of the spinlock, we acquire a
reference and mark the vma as active to prevent it from being unbound.
However, since it is tricky allocate an entry in the fence tree (doing
so would require taking a mutex) while inside the engine spinlock, we
use an atomic bit and special case the handling for i915_active_wait.

The core benefit is that we can use some non-atomic methods for mapping
the device pages, we can remove the slow compression phase out of atomic
context (i.e. stop antagonising the nmi-watchdog), and no we longer need
large reserves of atomic pages.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111215
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725223843.8971-1-chris@chris-wilson.co.uk

drm/i915/uc: Move uc firmware layout definitions to dedicated file

Generic uc firmware layout definitions are unlikely to change and
are separate to other GuC specific definitions.

v2: reordered

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725141308.24660-3-michal.wajdeczko@intel.com

drm/i915/uc: Update drawing for firmware layout

Sphinx was rendering firmware layout as html table, but since
we want to add sizes relations switch to plain text graphics.

v2: also update text and do it before move (Daniele)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725141308.24660-2-michal.wajdeczko@intel.com

drm/i915: Fix GuC documentation links

We moved GuC related files to new location but we missed to update
.rst file with links.

References: commit 0f261b241d9c ("drm/i915/uc: move GuC and HuC files under gt/uc/")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725141308.24660-1-michal.wajdeczko@intel.com

drm/i915/uc: Unify uC firmware upload

The way we load the firmwares is the same for both GuC and HuC, the only
difference is in the wopcm destination address and the dma flags, so we
easily can move the logic to a common function and pass in offset and
flags. The only other difference in the uplaod path are some the extra
steps that guc does before and after the xfer, but those don't require
the guc fw to be pinned in ggtt and can safely be performed before
calling the uc_upload function.

Note that this patch re-introduces the dma xfer wait for guc loading that
was removed with "drm/i915/guc: Propagate the fw xfer timeout". This is
not going to slow us down on a successful load (the dma has to complete
before fw init can start), but could slightly increase the timeout in case
of a fw init error.

v2: use _fw variants for uncore accesses (Chris), fix guc_fw status on
    failed wait.

v3: use dev_err and print DMA_CTRL (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-9-daniele.ceraolospurio@intel.com

drm/i915/uc: Plumb the gt through fw_upload

The gt is our new central structure for uc-related code, so we can use
that instead of jumping back to i915 via the fw object. Since we have it
in the upload function it is easy to pass it through the lower levels of
the xfer process instead of continuosly jumping via uc_fw->uc->gt, which
will also make things a bit cleaner for the next patch.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-8-daniele.ceraolospurio@intel.com

drm/i915/huc: Copy huc rsa only once

The binary is perma-pinned and the rsa is not going to change, so copy
it only once and not on every load.

v2: onion unwind (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Fernando Pacheco <fernando.pacheco@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-7-daniele.ceraolospurio@intel.com

drm/i915/uc: Move xfer rsa logic to common function

The way we copy the RSA is the same for GuC and HuC, so we can move the
logic in a common function. this will also make any update needed for
local memory easier.

v2: return the number of copied bytes and check it (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-6-daniele.ceraolospurio@intel.com

drm/i915/uc: Unify uc_fw status tracking

We currently track fetch and load status separately, but the 2 are
actually sequential in the uc lifetime (fetch must complete before we
can attempt the load!). Unifying the 2 variables we can better follow
the sequential states and improve our trackng of the uC state.

Also, sprinkle some GEM_BUG_ON to make sure we transition correctly
between states.

v2: rename states, add the running state (Michal), drop some logs in
    the fetch path (Michal, Chris)

v3: re-rename states, extend early status check to all helpers (Michal)

Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-5-daniele.ceraolospurio@intel.com

drm/i915/uc: Unify uC FW selection

Instead of having 2 identical functions for GuC and HuC firmware
selection, we can unify the selection logic and just use different lists
based on FW type.

Note that the revid is not relevant for current blobs, but the upcoming
CML will be identified as CFL rev 5, so by considering the revid we're
ready for that.

v2: rework blob list defs (Michal), add order check (Chris), fuse GuC
    and HuC lists into one.

v3: remove difference between no uC HW and no uC FW, simplify related
    selection code, check the whole fw list (Michal)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v2
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-4-daniele.ceraolospurio@intel.com

drm/i915: Fix handling of non-supported uC

There are 2 issues around handling of missing uC support:

- We treat lack of uC HW and lack of uC FW definition as 2 different
  cases, but both of them mean that we don't support the uC on the
  platform we're running on.

- We rely on the modparam to decide if we can take uC paths or not, but
  we don't sanitize it if it is set incorrectly on platform with no uC
  support.

To fix both of them, unify the 2 cases in a single one and sanitize the
modparam on invalid configuration (after printing an error message).
The log has been adapted as well, since the user doesn't care why we
don't support GuC/HuC (no HW or no FW), just that we do not. Developers
can easily find the answer based on the platform, so we can simplify the
log.

Correcting the modparam has been preferred over failing the load since
this is what we usually do for non-supported feature (e.g. the now gone
enable_ppgtt would fall back to the highest supported PPGTT mode if the
selected one was not available).

Note that this patch purposely doesn't change the behavior for platforms
that do have uC support, in which case we will still fail if enable_guc
is set and the firmware is not available on the system.

Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-3-daniele.ceraolospurio@intel.com

drm/i915/uc: Unify uC platform check

We have several HAS_* checks for GuC and HuC but we mostly use HAS_GUC
and HAS_HUC, with only 1 exception. Since our HW always has either
both uC or neither of them, just replace all the checks with a unified
HAS_UC.

v2: use HAS_GT_UC (Michal)
v3: fix comment (Michal)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-2-daniele.ceraolospurio@intel.com

drm/i915/guc: Set GuC init params only once

All the GuC objects are perma-pinned, so their offset can't change at
runtime. We can therefore set (and log!) the parameters only once during
boot.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190724085849.18047-1-chris@chris-wilson.co.uk