And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index d392a67d4..8a06e5
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by: Lio
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 300 +-
drivers/gpu/drm/i915/i915_perf.h | 2 +
drivers/gpu/drm/i915/i915_perf_types.h | 328 +
3 files changed, 331 i
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
drivers/gpu/drm/i915/i915_perf
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/dr
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke thin
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
An upcoming change needs not to be interrupted.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_active.c | 4 +++-
drivers/gpu/drm/i915/i915_active.h | 5 ++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i91
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66406/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
C
Hi Lionel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc8 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 300 +-
drivers/gpu/drm/i915/i915_perf.h | 2 +
drivers/gpu/drm/i915/i915_perf_types.h | 328 +
3 files changed, 331 i
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by: Lio
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
drivers/gpu/drm/i915/i915_perf
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/dr
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
An upcoming change needs not to be interrupted.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_active.c | 4 +++-
drivers/gpu/drm/i915/i915_active.h | 5 ++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i91
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke thin
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
66b565b57b3f drm/i915: introduce a mechanism to extend execbuf2
-
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: introduce a mechanism to ext
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6852 -> Patchwork_14322
On 09/09/2019 08:12, Chris Wilson wrote:
And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/perf_pm
On Sat, Sep 07, 2019 at 07:12:56PM +0100, Chris Wilson wrote:
> The curse of using libigt where it is not wanted; in this case calling
> drop-caches while we hold the forcewake is a recipe for a long wait.
>
> Signed-off-by: Chris Wilson
For the series:
Reviewed-by: Petri Latvala
> ---
> too
Quoting Tvrtko Ursulin (2019-09-09 10:19:08)
>
> On 09/09/2019 08:12, Chris Wilson wrote:
> > And give up if we never even make it to the start.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > tests/perf_
Hi all,
This is just a few compilation fixes only seen on CI.
Cheers,
Lionel Landwerlin (13):
drm/i915: introduce a mechanism to extend execbuf2
drm/i915: add syncobj timeline support
drm/i915/perf: drop list of streams
drm/i915/perf: store the associated engine of a stream
drm/i915/pe
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.
Signed-off-by: Lio
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_perf.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/dr
An upcoming change needs not to be interrupted.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_active.c | 4 +++-
drivers/gpu/drm/i915/i915_active.h | 5 ++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i91
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should
Before we submit the first context to HW, we need to construct a valid
image of the register state. This layout is defined by the HW and should
match the layout generated by HW when it saves the context image.
Asserting that this should be equivalent should help avoid any undefined
behaviour and ve
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
drivers/gpu/drm/i915/i915_perf
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke thin
Include the active context register state when dumping the engine.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drive
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
Following a pattern used throughout the driver.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h| 300 +--
drivers/gpu/drm/i915/i915_perf.h | 2 +
drivers/gpu/drm/i915/i915_perf_types.h | 327 +
3 files changed, 330
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
On 09/09/2019 10:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-09 10:19:08)
On 09/09/2019 08:12, Chris Wilson wrote:
And give up if we never even make it to the start.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111592
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
On 07/09/2019 11:50, Chris Wilson wrote:
As we may unwind incomplete requests (for preemption) prior to
processing the CSB and the schedule-out events, we may update rq->engine
(resetting it to point back to the parent virtual engine) prior to
calling execlists_schedule_out(), invalidating the a
On Sat, Sep 07, 2019 at 11:19:55PM +, Mun, Gwan-gyeong wrote:
> On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > wrote:
> > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> > > >
> > > > > -Original Message-
>
Quoting Tvrtko Ursulin (2019-09-09 11:23:56)
>
> On 07/09/2019 11:50, Chris Wilson wrote:
> > As we may unwind incomplete requests (for preemption) prior to
> > processing the CSB and the schedule-out events, we may update rq->engine
> > (resetting it to point back to the parent virtual engine) pr
‐‐‐ Original Message ‐‐‐
On Monday, September 9, 2019 10:38 AM, wrote:
> With commit aa56a292ce623734ddd30f52d73f527d1f3529b5 (even on 5.3.0-rc8) I
> can get a system freeze during chromium compilation (likely due to jumbo /
> high memory usage). Sysrq still works and CPU/fan is low, s
With commit aa56a292ce623734ddd30f52d73f527d1f3529b5 (even on 5.3.0-rc8) I can
get a system freeze during chromium compilation (likely due to jumbo / high
memory usage). Sysrq still works and CPU/fan is low, so it seems like a
deadlock? and there's no disk reading. I can't read the dump gotten v
---
drivers/iommu/intel-iommu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 34f6a3d93ae2..c98cdfd91691 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -439,8 +439,6 @@ static int __init intel_iom
Being a "low-level" test, we opt to bypass the normal bind/unbind hooks
for the lower level insert_entries/clear_range. For ggtt, the
bind/unbind hooks provide the runtime wakeref and so we must also handle
this in exercising the low level hooks.
<4> [538.151672] RPM raw-wakeref not held
<4> [538.
Other than Broadwell being fubar (and Ironlake + g4x being special in
their own way), there appears to be little fallout from enabling iommu.
(The biggest open question is over performance, TLB misses are much more
expensive and that impacts meda/CL/GL throughput.) Enabling iommu/dmar
makes our CI
Currently, if there is time remaining before the start of the loop, we
do one full iteration over many possible different chunks within the
object. A full loop may take 50+s (depending on speed of indirect GTT
mmapings) and we try separately with LINEAR, X and Y -- at which point
igt times out. If
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 00786a142ff0..ebcb6dbc2393 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/
Despite the widespread and complete failure of Broadwell integrated
graphics when DMAR is enabled, known over the years, we have never been
able to root cause the issue. Instead, we let the failure undermine our
confidence in the iommu system itself when we should be pushing for it to
be always ena
As soon as we re-enable the various functions within the HW, they may go
off and read data via a GGTT offset. Hence, if we have not yet restored
the GGTT PTE before then, they may read and even *write* random locations
in memory.
Detected by DMAR faults during resume.
Signed-off-by: Chris Wilson
Be paranoid and make sure we flush any and all writes out of the WCB
before performing the UC mmio to update the RING_TAIL. (An UC write
should itself be enough to do the flush, hence the paranoia here.) Quite
infrequently, we see problems where the GPU seems to overshoot the
RING_TAIL and so execu
Quoting Prathap Kumar Valsan (2019-08-26 01:48:01)
> To provide shared last-level-cache isolation to cpu workloads running
> concurrently with gpu workloads, the gpu allocation of cache lines needs
> to be restricted to certain ways. Currently GPU hardware supports four
> class-of-service(CLOS) lev
== Series Details ==
Series: series starting with [CI,01/13] drm/i915: introduce a mechanism to
extend execbuf2
URL : https://patchwork.freedesktop.org/series/66418/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6852_full -> Patchwork_14322_full
==
For i965, add hw read out to create hw blob of gamma
lut values.
Review comments from old series:
https://patchwork.freedesktop.org/series/58039/
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assigning
intel_color_get_gamma_bit_precision() is extended for
cherryview by adding chv_gamma_precision(), i965 will use existing
i9xx_gamma_precision() func only.
Signed-off-by: Swati Sharma
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 25 +++--
1 file c
For cherryview, add hw read out to create hw blob of gamma
lut values.
Review comments from previous series:
https://patchwork.freedesktop.org/patch/328252
v4: -No need to initialize *blob [Jani]
-Removed right shifts [Jani]
-Dropped dev local var [Jani]
v5: -Returned blob instead of assi
In this patch series, added state checker to validate gamma lut values
for cherryview and i965 platforms. It's extension of the
patch series https://patchwork.freedesktop.org/patch/328246/?series=58039
which enabled the basic infrastructure and state checker for
few legacy platforms.
v2: Added la
Make it clear that the color adjust callback applies to the ggtt.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
2 files changed, 6
Try to tidy up the cache-coloring such that we rid the code of any
mm.color_adjust assumptions, this should hopefully make it more obvious
in the code when we need to actually use the cache-level as the color,
and as a bonus should make adding a different color-scheme simpler.
Signed-off-by: Matth
Export color_differs so that we can use it elsewhere.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 11 ---
drivers/gpu/drm/i915/i915_vma.h | 6 ++
3 fil
== Series Details ==
Series: series starting with [1/2] drm/i915: Show the logical context ring
state on dumping
URL : https://patchwork.freedesktop.org/series/66422/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3f29fa89a00e drm/i915: Show the logical context ring state on du
On 9/7/2019 4:37 PM, Animesh Manna wrote:
This patch adds a function, which will internally get the gem buffer
for DSB engine. The GEM buffer is from global GTT, and is mapped into
CPU domain, contains the data + opcode to be feed to DSB engine.
v1: Initial version.
v2:
- removed some unwanted
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro r
Quoting Matthew Auld (2019-09-09 13:40:52)
> Try to tidy up the cache-coloring such that we rid the code of any
> mm.color_adjust assumptions, this should hopefully make it more obvious
> in the code when we need to actually use the cache-level as the color,
> and as a bonus should make adding a di
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALI
On 9/7/2019 4:37 PM, Animesh Manna wrote:
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915
On 9/7/2019 4:37 PM, Animesh Manna wrote:
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
v
On 9/7/2019 4:37 PM, Animesh Manna wrote:
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneou
== Series Details ==
Series: series starting with [1/2] drm/i915: Show the logical context ring
state on dumping
URL : https://patchwork.freedesktop.org/series/66422/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6853 -> Patchwork_14323
===
On 9/7/2019 4:37 PM, Animesh Manna wrote:
The lifetime of command buffer can be controlled by the dsb user
throuh refcount. Added refcount mechanism is dsb get/put call
which create/destroy dsb context.
Cc: Jani Nikula
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i9
We wish to avoid our presentation worker from being blocked by normal
workloads if we want to maintain an interactive frame update.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Heinrich Fink
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 delet
Hi Fernando,
On Wednesday, August 28, 2019 2:45:57 AM CEST Fernando Pacheco wrote:
> It is not enough to check that uc supports GuC submission now
> that we can continue to load the driver after GuC initialization
> failure (support != enabled). Instead we should explicitly check
> that we enabled
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev17)
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f668eec43e67 drm/i915: introduce a mechanism to extend execbuf2
-:141: CHECK:SPACING: spaces prefe
Quoting Lionel Landwerlin (2019-07-26 14:38:40)
> On 17/07/2019 21:09, Tvrtko Ursulin wrote:
> >
> > On 17/07/2019 15:06, Chris Wilson wrote:
> >> Quoting Tvrtko Ursulin (2019-07-17 14:46:15)
> >>>
> >>> On 17/07/2019 14:35, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-07-17 14:23:55)
>
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev17)
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: introduce a mechanism to extend execbuf2
Okay!
Commit: drm/i
On 30-Aug-19 6:17 PM, Jani Nikula wrote:
On Fri, 30 Aug 2019, Swati Sharma wrote:
Add func intel_color_lut_equal() to compare hw/sw gamma
lut values. Since hw/sw gamma lut sizes and lut entries comparison
will be different for different gamma modes, add gamma mode dependent
checks.
v3: -Rebase
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev17)
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6853 -> Patchwork_14324
Summary
---
On Mon, 09 Sep 2019, "Sharma, Swati2" wrote:
> On 30-Aug-19 6:17 PM, Jani Nikula wrote:
>> On Fri, 30 Aug 2019, Swati Sharma wrote:
>>> Add func intel_color_lut_equal() to compare hw/sw gamma
>>> lut values. Since hw/sw gamma lut sizes and lut entries comparison
>>> will be different for differen
On Mon, Sep 09, 2019 at 05:14:05PM +0300, Jani Nikula wrote:
> On Mon, 09 Sep 2019, "Sharma, Swati2" wrote:
> > On 30-Aug-19 6:17 PM, Jani Nikula wrote:
> >> On Fri, 30 Aug 2019, Swati Sharma wrote:
> >>> Add func intel_color_lut_equal() to compare hw/sw gamma
> >>> lut values. Since hw/sw gamma
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: add INTEL_NUM_PIPES() and use
it (rev2)
URL : https://patchwork.freedesktop.org/series/66281/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cfe700484f5b drm/i915: add INTEL_NUM_PIPES() and use it
34659bd2039a
As per the display enable sequence, we need to follow the enable sequence
for slaves first with DP_TP_CTL set to Idle and configure the transcoder
port sync register to select the corersponding master, then follow the
enable sequence for master leaving DP_TP_CTL to idle.
At this point the transcode
In the transcoder port sync mode, the slave transcoders mask their vblanks
until master transcoder's vblank so while disabling them, make
sure slaves are disabled first and then the masters.
v4:
* Obtain slave state from master (Maarten)
v3:
* Rebase
v2:
* Use the intel_old_crtc_state_disables() h
== Series Details ==
Series: series starting with [1/6] drm/i915/selftests: Take runtime wakeref for
igt_ggtt_lowlevel
URL : https://patchwork.freedesktop.org/series/66425/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7386b0ebc23c drm/i915/selftests: Take runtime wakeref for
On 2019-09-08 at 19:44:35 +0300, Imre Deak wrote:
> On Sat, Sep 07, 2019 at 10:44:39PM +0530, Anshuman Gupta wrote:
Hi Imre,
Thanks for reviewing the pacthes i will rework the patches.
There are few comments from my side which will help to rework.
> > Add max_dc_state and tgl_set_target_dc_state()
On 9/7/19 1:39 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-06 23:28:05)
On 9/5/19 2:09 AM, Janusz Krzysztofik wrote:
When trying to reset a device with reset capability disabled or not
supported while rings are full of requests, it has been observed when
running in execl
kms_rotation_crc manually starts and stops CRC collection and reads
single CRC values when it needs them. Depending on how long the other
test setup and execution operations take, the CRC buffer (128 entries)
can fill up CRC values that the test never reads or uses. Our CI system
has stumbled ove
1 - 100 of 153 matches
Mail list logo
