Regards
Shashank
On 7/22/2017 12:34 AM, Imre Deak wrote:
On Fri, Jul 21, 2017 at 08:55:06PM +0530, Shashank Sharma wrote:
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
On 17-06-29 23:02:08, Ville Syrjälä wrote:
On Fri, Jun 23, 2017 at 09:45:44AM -0700, Ben Widawsky wrote:
v2:
Support sprite plane.
Support pipe C/D limitation on GEN9.
This requires rebase on the correct Ville patches
Cc: Daniel Stone
Cc: Kristian Høgsberg
Signed-off-by: Ben Widawsky
---
d
Ack, pls push.
-Daniel
On Fri, Jul 21, 2017 at 9:41 PM, Imre Deak wrote:
> The output of git pull into the rr-cache branch isn't really
> interesting, so suppress it like during the rest of rr-cache
> branch maintenance commands.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Imre Dea
The output of git pull into the rr-cache branch isn't really
interesting, so suppress it like during the rest of rr-cache
branch maintenance commands.
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Imre Deak
---
dim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dim b/di
On Fri, Jul 21, 2017 at 08:55:06PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26
Hi,
On 21-07-17 09:24, Daniel Vetter wrote:
Hi Greg&Hans,
How are we going to handle this now? The refactor is deeply burried in
drm-misc, I guess you could cherry-pick the relevant patches over. But
that'll probably lead to more conflicts because git will get confused.
Or you could just delet
On Fri, 2017-07-21 at 11:19 +0300, Paul Kocialkowski wrote:
> On Wed, 2017-07-19 at 16:50 +0300, Paul Kocialkowski wrote:
> > Nowadays, many VGA connectors are not actually native VGA but use a
> > discrete bridge to a digital connector. These bridges usually
> > enforce
> > their own EDID instead
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27727/
State : success
== Summary ==
Series 27727v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27727/revisions/1/mbox/
Test gem_exec_flush:
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
v3: Add some flex registers (Matthew)
v4: memset oa_config to 0 (Lionel)
Change error code for removing unexisting config EINVAL->ENOENT (Lionel)
v5: Update i9
On 18/07/17 19:14, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-07-18 18:18:52)
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
v3: Add some flex registers (Matthew)
v4: memset oa_config to 0 (Lionel)
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i
Here is another iteration which tries to address Chris' comments.
Cheers,
Lionel Landwerlin (3):
drm/i915/perf: fix flex eu registers programming
drm/i915/perf: prune OA configs
drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
drivers/gpu/drm/i915/i915_drv.c |2 +
drive
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
Reported-by: Matt
On 18/07/17 19:34, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-07-18 17:50:42)
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b824f8875c4..607484737f3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/
== Series Details ==
Series: drm/i915: Enforce that CS packets are qword aligned
URL : https://patchwork.freedesktop.org/series/27723/
State : success
== Summary ==
Series 27723v1 drm/i915: Enforce that CS packets are qword aligned
https://patchwork.freedesktop.org/api/1.0/series/27723/revisio
== Series Details ==
Series: YCBCR 4:2:0 handling in i915 layer (rev2)
URL : https://patchwork.freedesktop.org/series/27412/
State : success
== Summary ==
Series 27412v2 YCBCR 4:2:0 handling in i915 layer
https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/2/mbox/
Test gem_exec_f
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove assertion from raw
__i915_vma_unpin()
URL : https://patchwork.freedesktop.org/series/27714/
State : warning
== Summary ==
Series 27714v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27714/
Quoting Chris Wilson (2017-07-21 17:11:01)
> We require the caller to ensure that the packets they wish to emit into
> the CS ring are qword aligned (i.e. have an even number of dwords).
> Double check this.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> ---
> dri
We require the caller to ensure that the packets they wish to emit into
the CS ring are qword aligned (i.e. have an even number of dwords).
Double check this.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
1 file changed,
On Fri, Jul 21, 2017 at 2:59 PM, Chris Wilson wrote:
> My dream would be for the system to recognise which tests provide
> coverage for a patch and rank them by relevance and then run until death
> or timeout. Without such introspection, the best we can do is to have
> the developer supply the sel
On Fri, Jul 21, 2017 at 2:02 PM, Martin Peres
wrote:
> This is why I would rather use the execution time of tests as a way to tag
> the tests. What I want is to have a couple of options that brings me the
> best coverage in a certain amount of time:
> - BAT: 70% coverage in 10 minutes
> - FULL:
On Fri, Jul 21, 2017 at 5:13 PM, Jani Nikula
wrote:
> On Fri, 21 Jul 2017, Daniel Vetter wrote:
>> On Thu, Jul 20, 2017 at 6:23 PM, Martin Peres
>> wrote:
>>> Hi everyone,
>>>
>>> As some of you may already know, we have made great strides in making our CI
>>> system usable, especially in the la
On Fri, Jul 21, 2017 at 12:56 PM, Tvrtko Ursulin
wrote:
>
> On 20/07/2017 17:23, Martin Peres wrote:
>>
>> Hi everyone,
>>
>> As some of you may already know, we have made great strides in making our
>> CI system usable, especially in the last 6 months when everything started
>> clicking together.
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
V4: Rebase
V5: Added r-b from A
When output colorspace is YCBCR420, we have to load the
corresponding colorspace in AVI infoframe. This patch fills
the colorspace of AVI infoframe as per the output mode.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Checking RGB/YCBCR420 output only (Ville)
V7: Add colorspace inf
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbc
This patch series is a subset of series "YCBCR 4:2:0 handling in DRM layer"
Published and reviewed here: https://patchwork.freedesktop.org/series/26973/
The original series had 14 patches, out of which first 8 (which were in DRM
layer) are reviewed merged. These 6 patches are the I915 layer handli
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to perf
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
V2: rebase
V3: rebase
V4: rebase
V5: addressed review comments f
On Fri, 21 Jul 2017, Daniel Vetter wrote:
> On Thu, Jul 20, 2017 at 6:23 PM, Martin Peres
> wrote:
>> Hi everyone,
>>
>> As some of you may already know, we have made great strides in making our CI
>> system usable, especially in the last 6 months when everything started
>> clicking together.
>>
On Thu, Jul 20, 2017 at 12:35:27PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC
> HW state readout (rev2)
> URL : https://patchwork.freedesktop.org/series/27607/
> State : success
>
> == Summary ==
>
> Series 27
If we fail to acquire a fence (for old school fenced GPU access) then we
unwind the vma reservation, including its pin. However, we were making
the execobject as holding the pin before erring out, leading to a double
unpin:
[ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287!
[ 3193.9
The goal here was to minimise doing any thing or any check inside the
kernel that was not strictly required. For a userspace that assumes
complete control over the cache domains, the kernel is usually using
outdated information and may trigger clflushes where none were
required.
However, swapping
I was being overly paranoid in not updating the execobject.offset after
performing the fallback copy where we set reloc.presumed_offset to -1.
The thinking was to ensure that a subsequent NORELOC execbuf would be
forced to process the invalid relocations. However this is overkill so
long as we *onl
A couple of regression fixes that have been outstanding for a few weeks,
plus a pair of recent findings
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
cleanup. However, on an overflow the pin_count bitfield will be zero,
triggering an assertion, even though we the intention is to merely warn
and report the error back to the user (as historically the culprit has
be a leak in the
On Fri, Jul 21, 2017 at 07:36:22PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Friday 21 July 2017 06:56 PM, Imre Deak wrote:
> > On Fri, Jul 21, 2017 at 06:44:24PM +0530, Mahesh Kumar wrote:
> > > Hi,
> > >
> > >
> > > On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
> > > > The crtc state st
Quoting Chris Wilson (2017-07-21 13:32:33)
> If the request has been completed before the reset took effect, we don't
> need to mark it up as being a victim. Touching fence->error after the
> fence has been signaled is detected by dma_fence_set_error() and
> triggers a BUG:
[snip]
I've applied al
On 21/07/2017 14:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 14:00:27)
From: Tvrtko Ursulin
No need to sync filesystems when only listing subtest.
Extremely marginal benefit of avoid a short stall after make
followed by listing subtests.
Ah, I was looking for the sync recent
Hi,
On Friday 21 July 2017 06:56 PM, Imre Deak wrote:
On Fri, Jul 21, 2017 at 06:44:24PM +0530, Mahesh Kumar wrote:
Hi,
On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
The crtc state starts out being bzero'd, so no need to clear
scaler_users. Also intel_crtc_init_scalers() knows already
On Thu, Jul 06, 2017 at 05:40:40PM +0300, Imre Deak wrote:
> Shuffle the power well->domain mapping macros around so they are at one
> place in old->new GEN order.
>
> Signed-off-by: Imre Deak
Reviewed-by: Arkadiusz Hiler
___
Intel-gfx mailing list
Int
On Thu, Jul 06, 2017 at 05:40:39PM +0300, Imre Deak wrote:
> Move the helper next to the rest of HSW specific code.
>
> Signed-off-by: Imre Deak
Reviewed-by: Arkadiusz Hiler
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freed
On Tue, Jul 11, 2017 at 11:42:36PM +0300, Imre Deak wrote:
> After the previous refactorings the HSW/BDW and GEN9+ power well helpers
> are practically identical, so use the HSW power well helpers for GEN9+
> too. This means using the HSW power well ops instead of the SKL one and
> setting the irq_
On Fri, Jul 21, 2017 at 02:32:55PM +0300, Arkadiusz Hiler wrote:
> On Fri, Jul 21, 2017 at 02:25:18PM +0300, Imre Deak wrote:
> > On Fri, Jul 21, 2017 at 02:14:33PM +0300, Arkadiusz Hiler wrote:
> > > On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> > > > Atm we enable/disable a power w
On Fri, Jul 21, 2017 at 06:44:24PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
> > The crtc state starts out being bzero'd, so no need to clear
> > scaler_users. Also intel_crtc_init_scalers() knows already which
> > platforms have scalers, so no nee
Quoting Tvrtko Ursulin (2017-07-21 14:00:27)
> From: Tvrtko Ursulin
>
> No need to sync filesystems when only listing subtest.
>
> Extremely marginal benefit of avoid a short stall after make
> followed by listing subtests.
Ah, I was looking for the sync recently, to move it to common_init()
al
On Tue, Jul 11, 2017 at 11:42:35PM +0300, Imre Deak wrote:
> The pattern of a power well backing a set of fuses whose initialization
> we need to wait for during power well enabling is common to all GEN9+
> platforms. Adding support for this to the HSW power well enable helper
> allows us to use th
Hi,
On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
The crtc state starts out being bzero'd, so no need to clear
scaler_users. Also intel_crtc_init_scalers() knows already which
platforms have scalers, so no need for the platform check here.
Similarly intel_crtc_init_scalers() will init sca
On Thu, Jul 06, 2017 at 05:40:36PM +0300, Imre Deak wrote:
> Similarly to GEN9+ waiting for the power well disabled state is a safer
> option and also provides diagnostic info if the disabling didn't succeed
> or the power well was forced on by an external requester. While at it
> also use the exis
== Series Details ==
Series: series starting with [01/20] drm/i915: Report execlists irq bit in
debugfs
URL : https://patchwork.freedesktop.org/series/27700/
State : failure
== Summary ==
Series 27700v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27700/revisio
Sorry for late response.
On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
CP States defined:
DRM_CP_UN
== Series Details ==
Series: series starting with [01/20] drm/i915: Report execlists irq bit in
debugfs
URL : https://patchwork.freedesktop.org/series/27700/
State : failure
== Summary ==
Series 27700v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27700/revisio
On Wed, Jul 12, 2017 at 06:54:13PM +0300, Imre Deak wrote:
> The pattern of a power well backing a set of pipe IRQ or VGA
> functionality applies to all HSW+ platforms. Using power well attributes
> instead of platform checks to decide whether to init/reset pipe IRQs and
> VGA correspondingly is cl
Hi
On Friday 21 July 2017 06:20 PM, Imre Deak wrote:
On Fri, Jul 21, 2017 at 05:41:13PM +0530, Mahesh Kumar wrote:
Hi,
On Thursday 20 July 2017 08:19 PM, Sharma, Shashank wrote:
Acked-by: Shashank Sharma
Regards
Shashank
On 7/20/2017 4:20 AM, Imre Deak wrote:
The scaler allocation code d
From: Tvrtko Ursulin
No need to sync filesystems when only listing subtest.
Extremely marginal benefit of avoid a short stall after make
followed by listing subtests.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib
I think Chris' comments show this isn't actually tested.
Can you please write at least one test case for igt ?
We have a pretty long list of patches that need to land (still need
review on some patches).
I would recommend you base you patches on this :
https://github.com/djdeath/intel-gpu-tool
Quoting Martin Peres (2017-07-21 13:02:47)
> On 21/07/17 14:27, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
> >>
> >> On 21/07/2017 11:36, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
> From: Tvrtko Ursulin
> >>
> >> [snip]
> >>
> --- a/
On Fri, Jul 21, 2017 at 05:41:13PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Thursday 20 July 2017 08:19 PM, Sharma, Shashank wrote:
> > Acked-by: Shashank Sharma
> >
> > Regards
> > Shashank
> > On 7/20/2017 4:20 AM, Imre Deak wrote:
> > > The scaler allocation code depends on a non-zero defau
On Thu, Jul 06, 2017 at 05:40:34PM +0300, Imre Deak wrote:
> Although on HSW/BDW there is only a single display global power well,
> it's programmed the same way as other GEN9+ power wells. This also
> means we can get at the HSW/BDW request and status flags the same way
> it's done on GEN9+ by ass
When doing a GPU reset, the CSB register will be trashed and we will
lose any context-switch notifications that happened since the tasklet
was disabled. If we find that all requests on this engine were
completed, we want to make sure that the ELSP tracker is similarly empty
so that we do not feed b
Triggering a GPU reset for one engine affects another, notably
corrupting the context status buffer (CSB) effectively losing track of
inflight requests.
Adding a few printks:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ad41836fa5e5..a969456bc0fa 100644
---
Since we make call i915_gem_context_mark_guilty() concurrently when
resetting different engines in parallel, we need to make sure that our
updates are safe for the unlocked access.
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/
Although a banned context will be told to -EIO off if they try to submit
more requests, we have a discrepancy between whole device resets and
per-engine resets where we report the GPU reset but not the engine
resets. This leaves a bit of mystery as to why the context was banned,
and also reduces aw
During our selftests, we try reseting the GPU tens of thousands of
times, flooding the dmesg with out reset spam drowning out any potential
warnings. Add an option to i915_reset()/i915_reset_engine() to specify a
quiet reset for selftesting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i
If all goes well, resetting one engine should not affect the operation of
any others. So to test this, we setup a continuous stream of requests
onto to each of the "innocent" engines whilst constantly resetting our
target engine.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
The purpose of the test was to check per-engine resets would fallback to
the global reset when required, but first we actually need a test for a
basic i915_handle_error()!
Cc: Mika Kuoppala
Cc: Michel Thierry
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 74
Extract the common barrier against rogue hangchecks from disrupting our
direct testing of resets, and in the process expand the lock to include
the per-engine reset shortcuts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c
We need to be able to reclaim from any process context, including the
shrinker. We can simulate being inside the shrinker using lockdep and
adjusting the task's reclaim state.
References: https://bugs.freedesktop.org/show_bug.cgi?id=101857
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/sel
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
triggers a BUG:
[ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.74315
As part of the knowing whether there is outstanding data in the CSB,
also check whether there is an outstanding IRQ notification.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
1 file changed, 4 i
Before we declare an engine as idle, check if there are any pending
execlist context-switches and if the ring itself reports as idle.
Otherwise, we may be left in a situation where we miss a crucial
execlist event (or something more sinister) yet the requests complete.
Since the seqno write happens
After setting the WEDGED bit, make sure that we do wake up waiters as
they may not be waiting for a request completion yet, just for its
execution.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Including a check against the execlist queue before calling the engine
idle and passing hangcheck.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/
When the GPU is reset, we want to discard all pending notifications as
either we have manually completed them, or they are no longer
applicable. Make sure we do reset the engine->irq_posted prior to
re-enabling the engine (e.g. the interrupt tasklets) in
i915_gem_reset_finish_engine().
Signed-off-
We rely on disabling the execlists (by stopping the tasklet) to prevent
new requests from submitting to the engine ELSP before we are ready.
However, we re-enable the engine before we call init_hw which gives
userspace the opportunity to subit a new request which is then
overwritten by init_hw -- b
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_g
When we wedge the device, we clear out the in-flight requests and
advance the breadcrumb to indicate they are complete. However, the
breadcrumb advance includes an assert that the engine is idle, so that
advancement needs to be the last step to ensure we pass our own sanity
checks.
Signed-off-by:
intel_engine_init_globa_seqno() may be called from an uncontrolled
set-wedged path where we have given up waiting for broken hw and declare
it defunct. Along that path, any sanity checks that the hw is idle
before we adjust its state will expectedly fail, so we simply cannot.
Instead of asserting i
We try to fixup the context image after the reset to ensure that there
are no more pending writes from the hw that may conflict and to fixup
any that were in flight.
Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvr
On 21/07/17 15:17, Tvrtko Ursulin wrote:
On 21/07/2017 13:02, Martin Peres wrote:
On 21/07/17 14:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a
On 21/07/2017 13:02, Martin Peres wrote:
On 21/07/17 14:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/ge
Hi,
On Thursday 20 July 2017 08:19 PM, Sharma, Shashank wrote:
Acked-by: Shashank Sharma
Regards
Shashank
On 7/20/2017 4:20 AM, Imre Deak wrote:
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even
On 21/07/17 14:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1492,47 +1492,47 @@
On 21/07/2017 12:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1492,47 +1492,47
On Thu, Jul 06, 2017 at 05:40:33PM +0300, Imre Deak wrote:
> We can reduce the code indentation by splitting the set helper to
> separate enable/disable helpers. This also allows us to unify the
> HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces
> some differences between the
On Thu, Jul 06, 2017 at 05:40:32PM +0300, Imre Deak wrote:
> Similarly to the GEN9 power well toggling, saving an occasional extra
> MMIO write is not worth the code complexity, let's simplify things.
>
> Signed-off-by: Imre Deak
Reviewed-by: Arkadiusz Hiler
_
On Fri, Jul 21, 2017 at 02:25:18PM +0300, Imre Deak wrote:
> On Fri, Jul 21, 2017 at 02:14:33PM +0300, Arkadiusz Hiler wrote:
> > On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> > > Atm we enable/disable a power well only if it wasn't already
> > > enabled/disabled respectively. The on
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
>
> On 21/07/2017 11:36, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
> >> From: Tvrtko Ursulin
>
> [snip]
>
> >> --- a/tests/gem_concurrent_all.c
> >> +++ b/tests/gem_concurrent_all.c
> >> @@ -1492,47 +1492,47 @@ run_mode(con
On Fri, Jul 21, 2017 at 02:14:33PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> > Atm we enable/disable a power well only if it wasn't already
> > enabled/disabled respectively. The only reason for this I can think of
> > is to save the extra MMIO wri
On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> Atm we enable/disable a power well only if it wasn't already
> enabled/disabled respectively. The only reason for this I can think of
> is to save the extra MMIO writes. Since the HW state matches the power
> well's usage counter most of
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1492,47 +1492,47 @@ run_mode(const char *prefix,
igt_subtest_group {
Quoting Zhenyu Wang (2017-07-19 06:39:48)
> +static struct i915_gem_context *
> +lookup_context_hw_id(struct drm_i915_private *dev_priv, unsigned int hw_id)
> +{
> + struct i915_gem_context *ctx;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(&dev_priv->drm);
> + i
On Thu, Jul 06, 2017 at 05:40:30PM +0300, Imre Deak wrote:
> We check already for power wells that are unexpectedly on (or forced on)
> during power well disabling. Those checks also account for other
> power well requesters like KVMR or DEBUG. As such this check is
> redundant, let's remove it to
On 20/07/2017 17:23, Martin Peres wrote:
Hi everyone,
As some of you may already know, we have made great strides in making
our CI system usable, especially in the last 6 months when everything
started clicking together.
The CI team is no longer overwhelmed with fires and bug reports, so we
Just a small nit down there.
On 19/07/17 06:39, Zhenyu Wang wrote:
In order to support profiling for special context e.g vGPU context,
we can expose vGPU context hw id and enable i915 perf property to
get target context for profiling. This adds new perf property to
assign target context with hw
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
> From: Tvrtko Ursulin
>
> Proposal to add test tags as a replacement for separate test
> list which can be difficult to maintain and get out of date.
>
> Putting this maintanenace inline with tests makes it easier
> to remember to update the (now imp
From: Tvrtko Ursulin
Proposal to add test tags as a replacement for separate test
list which can be difficult to maintain and get out of date.
Putting this maintanenace inline with tests makes it easier
to remember to update the (now implicit) lists, and also enables
richer test selection possib
On Fri, Jul 21, 2017 at 11:39 AM, Daniel Vetter wrote:
> On Thu, Jul 20, 2017 at 6:23 PM, Martin Peres
> wrote:
>> Hi everyone,
>>
>> As some of you may already know, we have made great strides in making our CI
>> system usable, especially in the last 6 months when everything started
>> clicking
On Thu, Jul 20, 2017 at 6:23 PM, Martin Peres
wrote:
> Hi everyone,
>
> As some of you may already know, we have made great strides in making our CI
> system usable, especially in the last 6 months when everything started
> clicking together.
>
> The CI team is no longer overwhelmed with fires and
1 - 100 of 105 matches
Mail list logo
