Currently, the backend scheduling code abuses struct_mutex into order to
have a global lock to manipulate a temporary list (without widespread
allocation) and to protect against list modifications. This is an
extraneous coupling to struct_mutex and further can not extend beyond
the local device.
As we are about to allow ourselves to slightly bump the user priority
into a few different sublevels, packthose internal priority lists
into the same i915_priolist to keep the rbtree compact and avoid having
to allocate the default user priority even after the internal bumping.
The downside to
In the next few patches, we will want to give a small priority boost to
some requests/queues but not so much that we perturb the user controlled
order. As such we shift the user priority bits higher leaving ourselves
a few low priority bits for our bumping.
Signed-off-by: Chris Wilson
---
Taken from an idea used for FQ_CODEL, we give new request flows a
priority boost. These flows are likely to correspond with interactive
tasks and so be more latency sensitive than the long queues. As soon as
the client has more than one request in the queue, further requests are
not boosted and it
If we are waiting for the currently executing request, we have a good
idea that it will be completed in the very near future and so want to
cap the CPU_DMA_LATENCY to ensure that we wake up the client quickly.
v2: Not allowed to block in kmalloc after setting TASK_INTERRUPTIBLE.
v3: Avoid the
Latency is in the eye of the beholder. In the case where a client stops
and waits for the gpu, give that request chain a small priority boost
(not so that it overtakes higher priority clients, to preserve the
external ordering) so that ideally the wait completes earlier.
Testcase:
On Fri, 2018-08-03 at 20:12 +0100, Chris Wilson wrote:
> Quoting Gwan-gyeong Mun (2018-08-03 17:41:50)
>
> Even for trivial patches, always include a changelog. In this case, I
> added "Trivial typo, s/loose/lose/, in i915_drm_resume."
>
> > Signed-off-by: Gwan-gyeong Mun
>
> Reviewed-by:
== Series Details ==
Series: Display Stream Compression enabling on eDP/DP (rev3)
URL : https://patchwork.freedesktop.org/series/47514/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/dp: Add DP DSC DPCD receiver capability size define and missing
SHIFT
Okay!
Commit:
Em Seg, 2018-08-06 às 21:22 +0100, Chris Wilson escreveu:
> Save the module parameters from setup and restore them on teardown,
> so
> that we leave the system in the same state as we found it.
Currently kms_fbt uses igt_set_module_param_int() which uses
igt_save_module_param(), which installs an
== Series Details ==
Series: Display Stream Compression enabling on eDP/DP (rev3)
URL : https://patchwork.freedesktop.org/series/47514/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4624 -> Patchwork_9864 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Em Seg, 2018-08-06 às 22:07 +0100, Chris Wilson escreveu:
> Quoting Paulo Zanoni (2018-08-06 21:56:15)
> > Em Seg, 2018-08-06 às 21:22 +0100, Chris Wilson escreveu:
> > > Save the module parameters from setup and restore them on
> > > teardown,
> > > so
> > > that we leave the system in the same
Quoting Matthew Auld (2018-08-06 19:53:47)
> On 6 August 2018 at 15:46, Chris Wilson wrote:
> > Experience teaches us over and over again that coherency on Baytrail
> > requires the odd heavy hammer, and in particular clflush alone is not
> > enough to guarrantee that writes from the CPU are
Quoting Chris Wilson (2018-08-06 18:21:45)
> Quoting Chris Wilson (2018-08-06 15:56:47)
> > A long time ago, we were afraid of handling interrupts and signaling
> > waiters during a reset, worrying that the confusion in request handling
> > would interfere with our attempts to process the reset in
On Wed 01-08-18 10:46:35, Dmitry Vyukov wrote:
> I guess it would be useful to have such extensive comment for each
> SLAB_TYPESAFE_BY_RCU use explaining why it is needed and how all the
> tricky aspects are handled.
>
> For example, the one in jbd2 is interesting because it memsets the
> whole
== Series Details ==
Series: Display Stream Compression enabling on eDP/DP (rev3)
URL : https://patchwork.freedesktop.org/series/47514/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4624_full -> Patchwork_9864_full =
== Summary - WARNING ==
Minor unknown changes coming
== Series Details ==
Series: Display Stream Compression enabling on eDP/DP (rev2)
URL : https://patchwork.freedesktop.org/series/47514/
State : failure
== Summary ==
Applying: drm/dp: Add DP DSC DPCD receiver capability size define and missing
SHIFT
Applying: drm/i915/dp: Cache the DP/eDP
After encoder->pre_enable() hook, after link training sequence is
completed, PPS registers for DSC encoder are configured using the
DSC state parameters in intel_crtc_state as part of DSC enabling
routine in the source. DSC enabling routine is called after
encoder->pre_enable() before enbaling the
After encoder->pre_enable() hook, after link training sequence is
completed, PPS registers for DSC encoder are configured using the
DSC state parameters in intel_crtc_state as part of DSC enabling
routine in the source. DSC enabling routine is called after
encoder->pre_enable() before enbaling the
Em Seg, 2018-08-06 às 12:58 +0300, Imre Deak escreveu:
> It makes sense to keep unchanging data const. Extract such fields
> from
> the i915_power_well struct into a new i915_power_well_desc struct
> that
> we initialize during compile time. For the rest of the dynamic
> fields allocate an array
Display Stream Splitter registers need to be programmed to enable
the joiner if two DSC engines are used and also to enable
the left and the right DSC engines. This happens as part of
the DSC enabling routine in the source in atomic commit.
v2:
* Rebase (Manasi)
Cc: Jani Nikula
Cc: Ville
== Series Details ==
Series: drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming
URL : https://patchwork.freedesktop.org/series/47774/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4622_full -> Patchwork_9862_full =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: Display Stream Compression enabling on eDP/DP (rev3)
URL : https://patchwork.freedesktop.org/series/47514/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
260bd82c6e63 drm/dp: Add DP DSC DPCD receiver capability size define and
missing SHIFT
Quoting Paulo Zanoni (2018-08-06 21:56:15)
> Em Seg, 2018-08-06 às 21:22 +0100, Chris Wilson escreveu:
> > Save the module parameters from setup and restore them on teardown,
> > so
> > that we leave the system in the same state as we found it.
>
> Currently kms_fbt uses
Hi Dave,
Initial fixes for 4.19. Starting by the one where gvt compilation gets
broken after a silent conflict between next and fixes.
Here goes drm-intel-next-fixes-2018-08-06:
- Fix gvt compilation broken on a silent conflict on fixes vs next merge
- Fix runtime PM for LPE audio
- Revert on
Em Seg, 2018-08-06 às 12:58 +0300, Imre Deak escreveu:
> Now that we removed dependence on the power well IDs to determine the
> control register and request/status flag offsets the only purpose of
> power well IDs is to look up power wells directly bypassing the power
> domains framework. However
== Series Details ==
Series: drm/i915: Re-apply "Perform link quality check, unconditionally during
long pulse" (rev2)
URL : https://patchwork.freedesktop.org/series/47694/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9861_full =
== Summary -
Save the module parameters from setup and restore them on teardown, so
that we leave the system in the same state as we found it.
Signed-off-by: Chris Wilson
---
tests/kms_frontbuffer_tracking.c | 43 +---
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git
Em Seg, 2018-08-06 às 12:58 +0300, Imre Deak escreveu:
> There is no need for separate IDs for power wells on a new platform
> with
> the same functionality as an other power well on a previous platform,
> we
> can just reuse the ID from the previous platform. This is only
> possible
> after the
On 2018.08.02 22:40:19 -0500, Gustavo A. R. Silva wrote:
> info.index can be indirectly controlled by user-space, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/gpu/drm/i915/gvt/kvmgt.c:1232
On 2018.07.19 11:19:21 +0300, Dan Carpenter wrote:
> The dma_mapping_error() returns true on error but we want to return
> -ENOMEM here.
>
> Fixes: 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages")
> Signed-off-by: Dan Carpenter
>
Applied, thanks!
> diff --git
== Series Details ==
Series: drm/i915: Pull seqno started checks together (rev2)
URL : https://patchwork.freedesktop.org/series/47753/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
95cd3d8b15e9 drm/i915: Pull seqno started checks together
-:69: CHECK:PARENTHESIS_ALIGNMENT:
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev2)
URL : https://patchwork.freedesktop.org/series/47680/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
93959254664e drm/i915: Add detection of changing of edid on
Since amdgpu is synchronous for exporting a dmabuf, exercise both paths
to highlight the issue.
v2: More action required to trigger the dmabuf-mapping
References: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Signed-off-by: Chris Wilson
---
tests/amdgpu/amd_prime.c | 47
== Series Details ==
Series: drm/i915: Clean up power well descriptors (rev2)
URL : https://patchwork.freedesktop.org/series/46952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6c5eac3775d7 drm/i915/icl: Fix power well anonymous union initializers
69d41b65c165 drm/i915:
== Series Details ==
Series: drm/i915: Pull seqno started checks together (rev2)
URL : https://patchwork.freedesktop.org/series/47753/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9857 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev2)
URL : https://patchwork.freedesktop.org/series/47680/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9858 =
== Summary - FAILURE ==
Serious
Since amdgpu is synchronous for exporting a dmabuf, exercise both paths
to highlight the issue.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Signed-off-by: Chris Wilson
---
tests/amdgpu/amd_prime.c | 27 +--
1 file changed, 21 insertions(+), 6
A long time ago, we were afraid of handling interrupts and signaling
waiters during a reset, worrying that the confusion in request handling
would interfere with our attempts to process the reset in an orderly
fashion. Since then, we have isolated our irq-driven request handling by
virtual of the
On 04/08/2018 00:24, Lucas De Marchi wrote:
After disabling resource streamer on ICL (due to it actually not
existing there), I got feedback that there have been some experimental
patches for mesa to use RS years ago, but nothing ever landed or shipped
because there was no performance
== Series Details ==
Series: drm/i915: Stop dropping irq around resets
URL : https://patchwork.freedesktop.org/series/47769/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9860 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Experience teaches us over and over again that coherency on Baytrail
requires the odd heavy hammer, and in particular clflush alone is not
enough to guarrantee that writes from the CPU are picked up by the CS.
Do as we do elsewhere and ensure we have an unconditional
i915_gem_chipset_flush() after
== Series Details ==
Series: drm/i915/selftests: Unconditionally do a chipset flush before
emit_bb_start
URL : https://patchwork.freedesktop.org/series/47767/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9859 =
== Summary - SUCCESS ==
No regressions
== Series Details ==
Series: drm/i915: Pull seqno started checks together (rev2)
URL : https://patchwork.freedesktop.org/series/47753/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9857_full =
== Summary - WARNING ==
Minor unknown changes coming
== Series Details ==
Series: series starting with [1/6] drm/i915: Limit C-states when waiting for
the active request
URL : https://patchwork.freedesktop.org/series/47739/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4618_full -> Patchwork_9855_full =
== Summary - FAILURE
The hotplug detection routine of i915 uses drm_helper_hpd_irq_event(). This
helper can detect changing of status of connector, but it can not detect
changing
of edid. Following scenario requires detection of changing of edid.
1) plug display device to a connector
2) system suspend
3) unplug
On 06/08/2018 09:30, Chris Wilson wrote:
Latency is in the eye of the beholder. In the case where a client stops
and waits for the gpu, give that request chain a small priority boost
(not so that it overtakes higher priority clients, to preserve the
external ordering) so that ideally the wait
We have a few instances of checking seqno-1 to see if the HW has started
the request. Pull those together under a helper.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 9 +++---
drivers/gpu/drm/i915/i915_request.h
Quoting Mika Kuoppala (2018-08-06 12:12:15)
> Chris Wilson writes:
>
> > By using TYPESAFE_BY_RCU, we accept that requests may be swapped out from
> > underneath us, even when using rcu_read_lock(). We use a strong barrier
> > on acquiring the refcount during lookup, but this needs to be paired
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-06 12:12:15)
>> Chris Wilson writes:
>>
>> > By using TYPESAFE_BY_RCU, we accept that requests may be swapped out from
>> > underneath us, even when using rcu_read_lock(). We use a strong barrier
>> > on acquiring the refcount during
== Series Details ==
Series: series starting with [1/6] drm/i915: Limit C-states when waiting for
the active request
URL : https://patchwork.freedesktop.org/series/47739/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4618 -> Patchwork_9855 =
== Summary - SUCCESS ==
No
On 06/08/2018 10:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-06 10:34:54)
On 06/08/2018 09:30, Chris Wilson wrote:
If we are waiting for the currently executing request, we have a good
idea that it will be completed in the very near future and so want to
cap the CPU_DMA_LATENCY
On 06/08/2018 11:03, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-06 10:53:52)
On 06/08/2018 09:30, Chris Wilson wrote:
Latency is in the eye of the beholder. In the case where a client stops
and waits for the gpu, give that request chain a small priority boost
(not so that it
On 06/08/2018 09:30, Chris Wilson wrote:
If we are waiting for the currently executing request, we have a good
idea that it will be completed in the very near future and so want to
cap the CPU_DMA_LATENCY to ensure that we wake up the client quickly.
I cannot shake the opinion that we
On 06/08/2018 09:30, Chris Wilson wrote:
Taken from an idea used for FQ_CODEL, we give new request flows a
priority boost. These flows are likely to correspond with interactive
tasks and so be more latency sensitive than the long queues. As soon as
the client has more than one request in the
The callbacks these asserts are called from are used from a single power
well, so not much point in checking that. The check also requires a unique
power well ID that we would need to keep around only for this purpose.
(A follow-up patch removes power well IDs not needed for direct power
well
intel_power_domains_fini() rolls back what was done in
intel_power_domains_init_hw(), so rename and move it accordingly. This
allows us adding a cleanup function later for intel_power_domains_init()
in a cleaner way.
No functional change.
v2:
- Fix checkpatch error adding missing param name to
The format for the ID names is _DISP_PW_* so rename the IDs
not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll
change that to use another existing ID in the next patch.
v2:
- Fix line over 80 chars checkpatch warning.
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting
Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add
There is no need for separate IDs for power wells on a new platform with
the same functionality as an other power well on a previous platform, we
can just reuse the ID from the previous platform. This is only possible
after the previous patches where we removed dependence on the actual
enum
On ICL there are 5 fused power gates, so add the two missing ones for
clarity.
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Imre Deak
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of
This is v2 of [1], fixing the issues Paulo noticed.
[1] https://patchwork.freedesktop.org/series/46952/
Cc: Chris Wilson
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Cc: Rodrigo Vivi
Imre Deak (10):
drm/i915/icl: Fix power well anonymous union initializers
drm/i915: Rename
Similarly to commit 0a445945be6d
("drm/i915: Work around GCC anonymous union initialization bug")
we need to initialize anonymous unions inside extra braces to work
around a GCC4.4 build error.
v2:
- Fix checkpatch errors in commit log. (Paulo)
Cc: Chris Wilson
Cc: Ville Syrjala
Cc: Paulo
Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions
Chris Wilson writes:
> By using TYPESAFE_BY_RCU, we accept that requests may be swapped out from
> underneath us, even when using rcu_read_lock(). We use a strong barrier
> on acquiring the refcount during lookup, but this needs to be paired
> with a barrier on re-initialising it. Currently we
== Series Details ==
Series: series starting with [1/6] drm/i915: Limit C-states when waiting for
the active request
URL : https://patchwork.freedesktop.org/series/47739/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ffbc30b340a9 drm/i915: Limit C-states when waiting for the
== Series Details ==
Series: series starting with [1/6] drm/i915: Limit C-states when waiting for
the active request
URL : https://patchwork.freedesktop.org/series/47739/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Limit C-states when waiting for the active
Quoting Tvrtko Ursulin (2018-08-06 10:53:52)
>
> On 06/08/2018 09:30, Chris Wilson wrote:
> > Latency is in the eye of the beholder. In the case where a client stops
> > and waits for the gpu, give that request chain a small priority boost
> > (not so that it overtakes higher priority clients, to
== Series Details ==
Series: drm/i915: Clean up power well descriptors (rev2)
URL : https://patchwork.freedesktop.org/series/46952/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/icl: Fix power well anonymous union initializers
Okay!
Commit: drm/i915: Rename
Chris Wilson writes:
> We have a few instances of checking seqno-1 to see if the HW has started
> the request. Pull those together under a helper.
>
Could you elaborate why you want both completed and signaled?
Otherwise it looks good.
-Mika
> Suggested-by: Tvrtko Ursulin
> Signed-off-by:
Quoting Mika Kuoppala (2018-08-06 12:17:16)
> Chris Wilson writes:
>
> > We have a few instances of checking seqno-1 to see if the HW has started
> > the request. Pull those together under a helper.
> >
>
> Could you elaborate why you want both completed and signaled?
Purely on context. In
== Series Details ==
Series: drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming
URL : https://patchwork.freedesktop.org/series/47774/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4622 -> Patchwork_9862 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: drm/i915/selftests: Unconditionally do a chipset flush before
emit_bb_start
URL : https://patchwork.freedesktop.org/series/47767/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9859_full =
== Summary - WARNING ==
Minor
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an
acer Veriton N4640G usable again.
This hunk was
== Series Details ==
Series: drm/i915: Re-apply "Perform link quality check, unconditionally during
long pulse" (rev2)
URL : https://patchwork.freedesktop.org/series/47694/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621 -> Patchwork_9861 =
== Summary - SUCCESS ==
Quoting Chris Wilson (2018-08-06 15:56:47)
> A long time ago, we were afraid of handling interrupts and signaling
> waiters during a reset, worrying that the confusion in request handling
> would interfere with our attempts to process the reset in an orderly
> fashion. Since then, we have isolated
Add the newly added slice_row_per_frame parameter
in the Picture Parameter Set registers.
Credits to Manasi for noticing bSpec change.
Suggested-by: Manasi Navare
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
1 file changed, 1 insertion(+)
diff
Quoting Anuj Phogat (2018-08-03 20:24:09)
>
>
> On Mon, Jul 30, 2018 at 5:07 AM Mika Kuoppala
> wrote:
>
> The register for 0xe420 is unable to hold any value, including
> this bit. The documentation is also mixed between having a
> register bit for toggle and having a state
Quoting Tvrtko Ursulin (2018-08-06 16:31:48)
>
> On 04/08/2018 00:24, Lucas De Marchi wrote:
> > After disabling resource streamer on ICL (due to it actually not
> > existing there), I got feedback that there have been some experimental
> > patches for mesa to use RS years ago, but nothing ever
On Fri, Jul 13, 2018 at 02:29:58PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-07-12 13:58:11)
> > On Thu, Jul 12, 2018 at 09:41:07AM +0100, Chris Wilson wrote:
> > > Quoting Chris Wilson (2018-07-12 09:36:33)
> > > > Signed-off-by: Chris Wilson
> > > > ---
> > > >
Quoting Tvrtko Ursulin (2018-08-06 10:34:54)
>
> On 06/08/2018 09:30, Chris Wilson wrote:
> > If we are waiting for the currently executing request, we have a good
> > idea that it will be completed in the very near future and so want to
> > cap the CPU_DMA_LATENCY to ensure that we wake up the
We have a few instances of checking seqno-1 to see if the HW has started
the request. Pull those together under a helper.
v2: Pull the !seqno assertion higher, as we given seqno==1 we may indeed
check to see if we have started using seqno==0.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris
== Series Details ==
Series: drm/i915: Stop dropping irq around resets
URL : https://patchwork.freedesktop.org/series/47769/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4621_full -> Patchwork_9860_full =
== Summary - WARNING ==
Minor unknown changes coming with
On Mon, Aug 06, 2018 at 10:33:48AM -0700, Anusha Srivatsa wrote:
> Add the newly added slice_row_per_frame parameter
> in the Picture Parameter Set registers.
>
Might be helpful to specify that this indicates number of slices
stacked in vertical direction when DSC is enabled.
With this:
On 6 August 2018 at 15:46, Chris Wilson wrote:
> Experience teaches us over and over again that coherency on Baytrail
> requires the odd heavy hammer, and in particular clflush alone is not
> enough to guarrantee that writes from the CPU are picked up by the CS.
> Do as we do elsewhere and ensure
86 matches
Mail list logo
