<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm/i915/intel_lrc.c, branch linux-4.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-07-08T13:32:20Z</updated>
<entry>
<title>drm/i915: Enable provoking vertex fix on Gen9 systems.</title>
<updated>2018-07-08T13:32:20Z</updated>
<author>
<name>Kenneth Graunke</name>
<email>kenneth@whitecape.org</email>
</author>
<published>2018-06-15T19:06:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3642628920063b47471a40d93891b0781564efe8'/>
<id>urn:sha1:3642628920063b47471a40d93891b0781564efe8</id>
<content type='text'>
commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb upstream.

The SF and clipper units mishandle the provoking vertex in some cases,
which can cause misrendering with shaders that use flat shaded inputs.

There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
(for the clipper) that work around the issue.  These registers are
unfortunately not part of the logical context (even the power context),
and so we must reload them every time we start executing in a context.

Bugzilla: https://bugs.freedesktop.org/103047
Signed-off-by: Kenneth Graunke &lt;kenneth@whitecape.org&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: stable@vger.kernel.org
(cherry picked from commit b77422f80337d363eed60c8c48db9cb6e33085c9)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/execlists: Use rmb() to order CSB reads</title>
<updated>2018-05-14T12:09:04Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2018-05-11T12:11:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cd078bf95df29d827daca0274a9a13821c11eedb'/>
<id>urn:sha1:cd078bf95df29d827daca0274a9a13821c11eedb</id>
<content type='text'>
We assume that the CSB is written using the normal ringbuffer
coherency protocols, as outlined in kernel/events/ring_buffer.c:

    *   (HW)                              (DRIVER)
    *
    *   if (LOAD -&gt;data_tail) {            LOAD -&gt;data_head
    *                      (A)             smp_rmb()       (C)
    *      STORE $data                     LOAD $data
    *      smp_wmb()       (B)             smp_mb()        (D)
    *      STORE -&gt;data_head               STORE -&gt;data_tail
    *   }

So we assume that the HW fulfils its ordering requirements (B), and so
we should use a complimentary rmb (C) to ensure that our read of its
WRITE pointer is completed before we start accessing the data.

The final mb (D) is implied by the uncached mmio we perform to inform
the HW of our READ pointer.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105064
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
References: https://bugs.freedesktop.org/show_bug.cgi?id=106185
Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP")
References: 61bf9719fa17 ("drm/i915/cnl: Use mmio access to context status buffer")
Suggested-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Cc: Michał Winiarski &lt;michal.winiarski@intel.com&gt;
Cc: Rafael Antognolli &lt;rafael.antognolli@intel.com&gt;
Cc: Michel Thierry &lt;michel.thierry@intel.com&gt;
Cc: Timo Aaltonen &lt;tjaalton@ubuntu.com&gt;
Tested-by: Timo Aaltonen &lt;tjaalton@ubuntu.com&gt;
Acked-by: Michel Thierry &lt;michel.thierry@intel.com&gt;
Acked-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180511121147.31915-1-chris@chris-wilson.co.uk
(cherry picked from commit 77dfedb5be03779f9a5d83e323a1b36e32090105)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/execlists: Clear user-active flag on preemption completion</title>
<updated>2018-04-04T13:45:32Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2018-03-24T12:58:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=38057aa1639b74d5c1e0dc1ca7c22bc7a31de714'/>
<id>urn:sha1:38057aa1639b74d5c1e0dc1ca7c22bc7a31de714</id>
<content type='text'>
When cancelling the requests and clearing out the ports following a
successful preemption completion, also clear the active flag. I had
assumed that all preemptions would be followed by an immediate dequeue
(preserving the active user flag), but under rare circumstances we may
be triggering a preemption for the second port only for it to have
completed before the preemotion kicks in; leaving execlists-&gt;active set
even though the system is now idle.

We can clear the flag inside the common execlists_cancel_port_requests()
as the other users also expect the semantics of active being cleared.

Fixes: f6322eddaff7 ("drm/i915/preemption: Allow preemption between submission ports")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Michał Winiarski &lt;michal.winiarski@intel.com&gt;
Cc: Michel Thierry &lt;michel.thierry@intel.com&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180324125829.27026-1-chris@chris-wilson.co.uk
(cherry picked from commit eed7ec52f214bac2f25395ccaad610fbeb842a6e)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt</title>
<updated>2018-03-27T08:20:00Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2018-03-21T09:10:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=76cb9d314a5385020c3adabf563df8efe71c6325'/>
<id>urn:sha1:76cb9d314a5385020c3adabf563df8efe71c6325</id>
<content type='text'>
We were relying on the uncached reads when processing the CSB to provide
ourselves with the serialisation with the interrupt handler (so we could
detect new interrupts in the middle of processing the old one). However,
in commit 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD
from the HWSP") those uncached reads were eliminated (on one path at
least) and along with them our serialisation. The result is that we
would very rarely miss notification of a new interrupt and leave a
context-switch unprocessed, hanging the GPU.

Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Michel Thierry &lt;michel.thierry@intel.com&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@intel.com&gt;
Reviewed-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Reviewed-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Michel Thierry &lt;michel.thierry@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk
(cherry picked from commit 9153e6b7c85edbc89e874e5c83f86217c53dcfaf)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: add schedule out notification of preempted but completed request</title>
<updated>2018-03-08T11:50:11Z</updated>
<author>
<name>Weinan Li</name>
<email>weinan.z.li@intel.com</email>
</author>
<published>2018-03-06T02:15:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=702791f7f20473813e613b7899d2c5ba5dc86b04'/>
<id>urn:sha1:702791f7f20473813e613b7899d2c5ba5dc86b04</id>
<content type='text'>
There is one corner case missing schedule out notification of the preempted
request. The preempted request is just completed when preemption happen,
then it will be canceled and won't be resubmitted later, GVT-g will lost
the schedule out notification.

Here add schedule out notification if found the preempted request has been
completed.

v2:
- refine description, add completed check and notification in
  execlists_cancel_port_requests. (Chris)

v3:
- use ternary confitional, remove local variable. (Tvrtko)

Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Weinan Li &lt;weinan.z.li@intel.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Reviewed-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1520302557-25079-1-git-send-email-weinan.z.li@intel.com
</content>
</entry>
<entry>
<title>drm/i915: store all subslice masks</title>
<updated>2018-03-08T10:06:20Z</updated>
<author>
<name>Lionel Landwerlin</name>
<email>lionel.g.landwerlin@intel.com</email>
</author>
<published>2018-03-06T12:28:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8cc7669355136f8952779e6f60053c1284d59c4d'/>
<id>urn:sha1:8cc7669355136f8952779e6f60053c1284d59c4d</id>
<content type='text'>
Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymmetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

v2: Rework how we store total numbers in sseu_dev_info (Tvrtko)
    Fix CHV eu masks, was reading disabled as enabled (Tvrtko)
    Readability changes (Tvrtko)
    Add EU index helper (Tvrtko)

v3: Turn ALIGN(v, 8) / 8 into DIV_ROUND_UP(v, BITS_PER_BYTE) (Tvrtko)
    Reuse sseu_eu_idx() for setting eu_mask on CHV (Tvrtko)
    Reformat debug prints for subslices (Tvrtko)

v4: Change eu_mask helper into sseu_set_eus() (Tvrtko)

v5: With Haswell reporting masks &amp; counts, bump sseu_*_eus() functions
    to use u16 (Lionel)

v6: Fix sseu_get_eus() for &gt; 8 EUs per subslice (Lionel)

v7: Change debugfs enabels for number of subslices per slice, will
    need a small igt/pm_sseu change (Lionel)
    Drop subslice_total field from sseu_dev_info, rely on
    sseu_subslice_total() to recompute the value instead (Lionel)

v8: Remove unused function compute_subslice_total() (Lionel)

Signed-off-by: Lionel Landwerlin &lt;lionel.g.landwerlin@intel.com&gt;
Reviewed-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Acked-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180306122857.27317-2-lionel.g.landwerlin@intel.com
</content>
</entry>
<entry>
<title>drm/i915/icl: Add Indirect Context Offset for Gen11</title>
<updated>2018-03-07T13:07:39Z</updated>
<author>
<name>Michel Thierry</name>
<email>michel.thierry@intel.com</email>
</author>
<published>2018-03-02T16:15:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fd034c77b52703c19b7b60b1bf4eb129ebfffb31'/>
<id>urn:sha1:fd034c77b52703c19b7b60b1bf4eb129ebfffb31</id>
<content type='text'>
v2: rebased to intel_lr_indirect_ctx_offset
v3: rebase, move define to intel_lrc_reg.h

BSpec: 11740
Signed-off-by: Michel Thierry &lt;michel.thierry@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Reviewed-by: Oscar Mateo &lt;oscar.mateo@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-5-mika.kuoppala@linux.intel.com
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/icl: Enhanced execution list support</title>
<updated>2018-03-07T13:07:31Z</updated>
<author>
<name>Thomas Daniel</name>
<email>thomas.daniel@intel.com</email>
</author>
<published>2018-03-02T16:14:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=05f0addd9b108d4dfa6853122f453a445f241c2b'/>
<id>urn:sha1:05f0addd9b108d4dfa6853122f453a445f241c2b</id>
<content type='text'>
Enhanced Execlists is an upgraded version of execlists which supports
up to 8 ports. The lrcs to be submitted are written to a submit queue
(the ExecLists Submission Queue - ELSQ), which is then loaded on the
HW. When writing to the ELSP register, the lrcs are written cyclically
in the queue from position 0 to position 7. Alternatively, it is
possible to write directly in the individual positions of the queue
using the ELSQC registers. To be able to re-use all the existing code
we're using the latter method and we're currently limiting ourself to
only using 2 elements.

v2: Rebase.
v3: Switch from !IS_GEN11 to GEN &lt; 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
v5: Reword commit, rename regs to be closer to specs, turn off
    preemption (Daniele), reuse engine-&gt;execlists.elsp (Chris)
v6: use has_logical_ring_elsq to differentiate the new paths
v7: add preemption support, rename els to submit_reg (Chris)
v8: save the ctrl register inside the execlists struct, drop CSB
    handling updates (superseded by preempt_complete_status) (Chris)
v9: s/drm_i915_gem_request/i915_request (Mika)
v10: resolved conflict in inject_preempt_context (Mika)

Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Thomas Daniel &lt;thomas.daniel@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-4-mika.kuoppala@linux.intel.com
</content>
</entry>
<entry>
<title>drm/i915/icl: new context descriptor support</title>
<updated>2018-03-07T13:07:20Z</updated>
<author>
<name>Daniele Ceraolo Spurio</name>
<email>daniele.ceraolospurio@intel.com</email>
</author>
<published>2018-03-02T16:14:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ac52da6af826d05f02c03fcde4a0651d070783b2'/>
<id>urn:sha1:ac52da6af826d05f02c03fcde4a0651d070783b2</id>
<content type='text'>
Starting from Gen11 the context descriptor format has been updated in
the HW. The hw_id field has been considerably reduced in size and engine
class and instance fields have been added.

There is a slight name clashing issue because the field that we call
hw_id is actually called SW Context ID in the specs for Gen11+.

With the current size of the hw_id field we can have a maximum of 2k
contexts at any time, but we could use the sw_counter field (which is sw
defined) to increase that because the HW requirement is that
engine_id + sw id + sw_counter is a unique number.
GuC uses a similar method to support more contexts but does its tracking
at lrc level. To avoid doing an implementation that will need to be
reworked once GuC support lands, defer it for now and mark it as TODO.

v2: rebased, add documentation, fix GEN11_ENGINE_INSTANCE_SHIFT
v3: rebased, bring back lost code from i915_gem_context.c
v4: make TODO comment more generic
v5: be consistent with bit ordering, add extra checks (Chris)

Cc: Oscar Mateo &lt;oscar.mateo@intel.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Reviewed-by: Oscar Mateo &lt;oscar.mateo@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-3-mika.kuoppala@linux.intel.com
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/icl: Ringbuffer interrupt handling</title>
<updated>2018-03-05T14:26:28Z</updated>
<author>
<name>Tvrtko Ursulin</name>
<email>tvrtko.ursulin@intel.com</email>
</author>
<published>2018-03-02T16:14:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d4ccceb055912c2e5e15ec488cee3378ee4ca73c'/>
<id>urn:sha1:d4ccceb055912c2e5e15ec488cee3378ee4ca73c</id>
<content type='text'>
On Gen11 interrupt masks need to be clear to allow C6 entry.
We keep them all enabled knowing that we generate extra
interrupts.

v2: Rebase.
v3: Remove gen 11 extra check in logical_render_ring_init.
v4: Rebase fixes.
v5: Rebase/refactor.
v6: Rebase.
v7: Rebase.
v8: Update comment and commit message (Daniele)

Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Reviewed-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-1-mika.kuoppala@linux.intel.com
</content>
</entry>
</feed>
