On 13/07/17 05:27 PM, Michel Dänzer wrote:
> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Signed-off-by: Michel Dänzer
>> ---
>>
>> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
>> drivers, right?
>
> -Original Message-
> From: Thierry, Michel
> Sent: Tuesday, August 8, 2017 1:40 AM
> To: Chris Wilson ; intel-gfx@lists.freedesktop.org
> Cc: Dong, Chuanxiao ; Ursulin, Tvrtko
> ; Winiarski, Michal
On 08/08/2017 12:51 AM, Lofstedt, Marta wrote:
Thanks Clinton!
If you add:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100047
You have my Rb.
/Marta
Thanks Marta,
However I'm going to extend the functionality to read the EDID
block size like Daniel suggested. During testing
I didn't mean to add libdrm, sorry, there is a separate change for that.
I'll double check and test the drivers that don't implement the virtual.
Thanks for the quick reply!
-j
On Tue, Aug 8, 2017 at 4:50 PM, Dave Airlie wrote:
> On 9 August 2017 at 09:42, Joe Kniss
A bunch of these tests assume that the handle is looked up after the other
parameters are checked. Other than that, looks good.
Reviewed-by: Jason Ekstrand
On Tue, Aug 8, 2017 at 4:09 PM, Dave Airlie wrote:
> From: Dave Airlie
>
>
On 9 August 2017 at 09:42, Joe Kniss wrote:
> Because all drivers currently use gem objects for framebuffer planes,
> the virtual create_handle() is not required. This change adds a
> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> create_handle()
From: Dave Airlie
Some basic sync object interface tests
Signed-off-by: Dave Airlie
---
tests/Makefile.sources | 1 +
tests/syncobj_basic.c | 260 +
2 files changed, 261 insertions(+)
create mode
== Series Details ==
Series: tests/gem_exec_basic: Documentation for subtests
URL : https://patchwork.freedesktop.org/series/28524/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
27ff12f00c94a5363f581a4353f08bfde62c59c4 lib: Remove illegal instructions
On 08/07/2017 09:14 AM, Michal Wajdeczko wrote:
We will need them in G2H communication to properly handle
responses and requests from the Guc.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Daniele Ceraolo Spurio
== Series Details ==
Series: drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init (rev2)
URL : https://patchwork.freedesktop.org/series/28507/
State : success
== Summary ==
Series 28507v2 drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
This is an RFC for adding documentation to IGT subtests. Each subtest can have
something similar to a WHAT - explaining what the subtest actually does,
and a WHY - which explains a use case, if applicable. Additionally,
include comments for anything in the subtest code which can help
explain HOW
Bit 29 of SRD_CTL needs to have its value preserved according to the
B-Spec, so right before we write out the register we go ahead and read
the register and preserve the value of that bit before we write out
the configured register value.
v2: Spaces => tabs, minor name change, and commit message
On Tue, Aug 08, 2017 at 07:42:50PM +, Vivi, Rodrigo wrote:
> On Tue, 2017-08-08 at 08:51 -0700, Jim Bride wrote:
> > Bit 29 of SRD_CTL needs to have its value preserved,
>
> probably good to kind of quote spec somehow:
> "This field is used for hardware communication. Software must not
>
merged to dinq, thanks for the review.
On Tue, Aug 8, 2017 at 4:36 AM, Imre Deak wrote:
> On Thu, Aug 03, 2017 at 03:51:37PM -0700, Rodrigo Vivi wrote:
>> DDI_E is not supported on CNL-U and CNL-Y
>>
>> When adding the inital support we noticed DDI_E wasn't supported
>> and
we confirmed that with current supported CNL skus using IS_CANNONLAKE
is enogh for now.
So feel free to change that if and use
Reviewed-by: Rodrigo Vivi
on the v2
On Tue, Aug 1, 2017 at 1:23 PM, Vivi, Rodrigo wrote:
> + Art, couple
== Series Details ==
Series: drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev3)
URL : https://patchwork.freedesktop.org/series/28341/
State : success
== Summary ==
Series 28341v3 drm/i915/cnl: Removing missing DDI_E bits from CNL.
Hi Dave,
Here's the pull for the last week and a bit. It's rather large as I was on
vacation/moving last week. Although the patch count/diffstat is higher than
normal, we have a lot of medium-large sets included. That also explains why the
summary might seem a bit light.
Among the aforementioned
a long time ago I had agreed with Daniel that we would only add new
platforms after it was enabled by default on previous platforms.
a big reason for that is that we was willing to reduce the platforms
to validate and do better validation one by one before enabling.
However now I believe it would
On Tue, 2017-08-08 at 08:51 -0700, Jim Bride wrote:
> Bit 29 of SRD_CTL needs to have its value preserved,
probably good to kind of quote spec somehow:
"This field is used for hardware communication. Software must not
change this field."
> so right before we
> write out the register we go
DDI_E is not supported on CNL-U and CNL-Y
When adding the inital support we noticed DDI_E wasn't supported
and removed it on v4 and v5 of that patch.
However for some reason I missed or put back these 2 chunks.
Time to clean it up to avoid later confusion.
Fixes: 8bcd3dd41766 ("drm/i915/cnl:
== Series Details ==
Series: drm/i915/cnl: Removing missing DDI_E bits from CNL. (rev2)
URL : https://patchwork.freedesktop.org/series/28341/
State : warning
== Summary ==
Series 28341v2 drm/i915/cnl: Removing missing DDI_E bits from CNL.
DDI_E is not supported on CNL-U and CNL-Y
When adding the inital support we noticed DDI_E wasn't supported
and removed it on v4 and v5 of that patch.
However for some reason I missed or put back these 2 chunks.
Time to clean it up to avoid later confusion.
Fixes: 8bcd3dd41766 ("drm/i915/cnl:
On Tue, 8 Aug 2017 14:18:07 +0530
Kirti Wankhede wrote:
> On 8/7/2017 11:13 PM, Alex Williamson wrote:
> > On Mon, 7 Aug 2017 08:11:43 +
> > "Zhang, Tina" wrote:
> >
> >> After going through the previous discussions, here are some summaries may
Hi,
On 3 August 2017 at 12:00, Daniel Stone wrote:
> On 1 August 2017 at 17:58, Ben Widawsky wrote:
>> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
>> *dev_priv,
>> plane_formats = skl_plane_formats;
>>
Rather than using TEST_UNCOMPRESSED / TEST_COMPRESSED as alternately
either an int or a bool, change it to a bitfield enum.
This will let us add more parameters later to control framebuffer
generation.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 29
Will be used in later patches.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index c02a0433..50bb2ad6 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@
Create a new helper for generating and rendering the framebuffer, rather
than doing it inline with applying the configuration. This will be used
later to generate a different plane configuration.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 73
In preparation for also testing sprites.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 50bb2ad6..1a5cdcd4 100644
--- a/tests/kms_ccs.c
+++
Make sure the CCS modifier is supported on our plane, before we try to
use it on that plane.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 117 +++-
1 file changed, 116 insertions(+), 1 deletion(-)
diff --git
Some subtests were magically doing a for-each-pipe loop. Remove that,
and have all multi-pipe tests actually work across all pipes.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 62 +++--
1 file changed, 20
Also try to test CCS on available non-primary planes. However, as there
is not enough bandwidth to scan out both the primary and sprite planes
when using CCS (or even Y-tiled), fall back to linear for the primary
plane when using CCS for a sprite/cursor plane.
Signed-off-by: Daniel Stone
We don't need to align the framebuffer dimensions to the tile size. As
long as the pitch is aligned to the tile width, and the BO dimensions
can fit full tiles of both aligned pitch and aligned height, we don't
need to claim the FB itself is larger.
Signed-off-by: Daniel Stone
== Series Details ==
Series: drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
URL : https://patchwork.freedesktop.org/series/28507/
State : success
== Summary ==
Series 28507v1 drm/i915/psr: Preserve SRD_CTL bit 29 on PSR init
Bit 29 of SRD_CTL needs to have its value preserved, so right before we
write out the register we go ahead and read the register and preserve
the value of that bit before we write out the configured register value.
Cc: Rodrigo Vivi
Cc: Chris Wilson
== Series Details ==
Series: series starting with [1/6] drm/i915: Introduce intel_ddi_dp_level.
URL : https://patchwork.freedesktop.org/series/28499/
State : success
== Summary ==
Series 28499v1 Series without cover letter
== Series Details ==
Series: series starting with [1/2] lib: Add hooks for enabling ftrace
URL : https://patchwork.freedesktop.org/series/28491/
State : failure
== Summary ==
Making check in lib
make[1]: Entering directory '/home/cidrm/intel-gpu-tools/lib'
make check-recursive
make[2]:
== Series Details ==
Series: tools/null_state_gen: Don't upload color calc and depth stencil on gen6
URL : https://patchwork.freedesktop.org/series/28496/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
eeff6a1d9c4e2c195b30ad95ee36a58ef6ca3387
On 4 August 2017 at 12:20, Lionel Landwerlin
wrote:
> From: Robert Bragg
>
> Signed-off-by: Robert Bragg
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 806
>
Let's start converging CNL buf translations to same style
used on previous platforms. So first thing is to use the
standard signature so we don't need to propagate the voltage
check into other parts of the code, but only on the parts
that it is really useful.
Signed-off-by: Rodrigo Vivi
On clock recovery this function is called to find out
the max voltage swing level that we could go.
However gen 9 functions use the old buffer translation tables
to figure that out. That table is not valid for CNL
causing an invalid number of entries and an invalid selection
on the max voltage
No functional changes. But those functions will be needed
to get max level for HDMI and DP, so let's move those
up closer to other similar functions existent for previous
platforms.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 122
No functional changes. This only moves the DP level
selection to a separated function that will be later
used to organize better the vswing sequences.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 16 ++--
1 file changed, 10
Let's get a proper HDMI DDI entry level for vswing programming
sequences on CNL.
Spec doesn't specify any default for HDMI tables,
so let's pick the last entry as the default for now.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 5 -
1 file
Vswing sequences on BXT and CNL are equivalent
to the ddi buffer registers setting on other platforms.
For some reason it got aligned with skl_ddi_set_iboost what
is semantically incorrect. This forced us to keep skipping
ddi buffer translation tables on the platforms that has
the vswing
Quoting Mika Kuoppala (2017-08-08 14:36:59)
> Mika Kuoppala writes:
>
> > We were pointing the color calc and depth stencil states blindly
> > to an offset of 1k from bb start. This was foolhardy as it collides
> > with other state in the batch and results in a
Quoting Mika Kuoppala (2017-08-08 14:36:39)
> Chris Wilson writes:
>
> > As we may have just bound the renderstate into the GGTT for execution, we
> > need to ensure that the GTT TLB are also flushed.
> >
> > On snb-gt2, this would cause a random GPU hang at the start
Quoting Mika Kuoppala (2017-08-08 14:36:39)
> Chris Wilson writes:
>
> > As we may have just bound the renderstate into the GGTT for execution, we
> > need to ensure that the GTT TLB are also flushed.
> >
> > On snb-gt2, this would cause a random GPU hang at the start
== Series Details ==
Series: drm/i915: Perform an invalidate prior to executing golden renderstate
URL : https://patchwork.freedesktop.org/series/28497/
State : success
== Summary ==
Series 28497v1 drm/i915: Perform an invalidate prior to executing golden
renderstate
Mika Kuoppala writes:
> Mika Kuoppala writes:
>
>> Chris Wilson writes:
>>
>>> As we may have just bound the renderstate into the GGTT for execution, we
>>> need to ensure that the GTT TLB are also flushed.
Mika Kuoppala writes:
> Chris Wilson writes:
>
>> As we may have just bound the renderstate into the GGTT for execution, we
>> need to ensure that the GTT TLB are also flushed.
>>
>> On snb-gt2, this would cause a random GPU hang at the
Mika Kuoppala writes:
> We were pointing the color calc and depth stencil states blindly
> to an offset of 1k from bb start. This was foolhardy as it collides
> with other state in the batch and results in a wrecked state upload.
>
> Chris noticed that with snb
Chris Wilson writes:
> As we may have just bound the renderstate into the GGTT for execution, we
> need to ensure that the GTT TLB are also flushed.
>
> On snb-gt2, this would cause a random GPU hang at the start of a new
> context (e.g. boot) and on snb-gt1, it was
On Mon, Aug 07, 2017 at 04:33:40PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The idea behind using an illegal instruction was to hang the GPU must
> > faster than simply using the recursive batch. However, we stopped doing
> > so on gen8+ as the CS parser
As we may have just bound the renderstate into the GGTT for execution, we
need to ensure that the GTT TLB are also flushed.
On snb-gt2, this would cause a random GPU hang at the start of a new
context (e.g. boot) and on snb-gt1, it was causing the renderstate batch
to take ~10s. It was the GPU
Chris Wilson writes:
> In the null state batch, we try to load the CC_STATE_POINTERS, but pass
> in a pointer to invalid state for the color-calc and depth-stencil
> state. In the rendercopy batch this was imported from, the 1024 offset
> used is known to be 64bytes of
We were pointing the color calc and depth stencil states blindly
to an offset of 1k from bb start. This was foolhardy as it collides
with other state in the batch and results in a wrecked state upload.
Chris noticed that with snb gt1, it takes 10 seconds for renderstate batch
to complete. However
Quoting Petri Latvala (2017-08-08 13:54:46)
> On Tue, Aug 08, 2017 at 12:27:11PM +0100, Chris Wilson wrote:
>
> *snip*
>
> > +#define BIT(x) (1ul << (x))
> > +
> > +/* Only a single tracer in the kernel, so we can use a singleton */
> > +struct igt_ftrace {
> > + int dir;
> > +
> > +
At the time of commit 1f767e02d69f ("drm/i915: HWS must be in the
mappable region for g33"), drm_mm insertion would often default to
placing a new object high in the zone forcing us to specify that certain
HWSP must be bound within the low mappable region. Since then, drm_mm
has gained more
On Tue, Aug 08, 2017 at 12:27:11PM +0100, Chris Wilson wrote:
*snip*
> +#define BIT(x) (1ul << (x))
> +
> +/* Only a single tracer in the kernel, so we can use a singleton */
> +struct igt_ftrace {
> + int dir;
> +
> + unsigned long flags;
> +#define PID_SET BIT(0)
> +#define INCLUDE_SET
Hi,
On Monday 07 August 2017 04:18 PM, Maarten Lankhorst wrote:
The gen3 watermark calculations are converted to atomic,
but the wm update calls are still done through the legacy
functions.
This will make it easier to bisect things if they go wrong.
Signed-off-by: Maarten Lankhorst
Hi Daniel,
Thank you for the patch.
On Tuesday 25 Jul 2017 10:01:19 Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
I assume you meant drm_atomic_plane_set_property. With that fixed,
During debug we may want to investigate all communication
from the Guc. Add proper tracing macros in debug config.
v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal)
v3: use dedicated Kconfig (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo
Hi Hugh,
Could we get this patch merged? Or would you prefer us to merge through drm-tip?
For what it's worth, this is:
Reviewed-by: Joonas Lahtinen
Regards, Joonas
On pe, 2017-07-28 at 16:12 +0300, Kirill A. Shutemov wrote:
> On Tue, Jul 25, 2017 at
On Thu, Aug 03, 2017 at 03:51:37PM -0700, Rodrigo Vivi wrote:
> DDI_E is not supported on CNL-U and CNL-Y
>
> When adding the inital support we noticed DDI_E wasn't supported
> and removed it on v4 and v5 of that patch.
> However for some reason I missed or put back these 2 chunks.
>
> Time to
On Tue, Aug 08, 2017 at 10:34:46AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add has_psr-flag to gen9lp
> URL : https://patchwork.freedesktop.org/series/28488/
> State : failure
>
> == Summary ==
>
> Series 28488v1 drm/i915: Add has_psr-flag to gen9lp
>
Supplement dmesg with the function call graph to try and help identify
why the suspend failed. On the other hand, it may be very noisy and
perturb the system due to its overhead...
Signed-off-by: Chris Wilson
---
lib/igt_aux.c | 15 +++
1 file changed, 11
If the kernel has tracing support builtin, we can enable around
troublesome tests to obtain greater detail from the kernel that may
prove invaluable in debugging the problem.
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_core.c | 5 ++
Hi Arnd,
Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
>
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
>
== Series Details ==
Series: drm/i915: Convert gen4- watermarks to atomic. (rev3)
URL : https://patchwork.freedesktop.org/series/23954/
State : failure
== Summary ==
Series 23954v3 drm/i915: Convert gen4- watermarks to atomic.
> -Original Message-
> From: Zanoni, Paulo R
> Sent: Monday, August 7, 2017 5:54 PM
> To: Lofstedt, Marta ; intel-
> g...@lists.freedesktop.org
> Cc: Latvala, Petri
> Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase
The gen3 watermark calculations are converted to atomic,
but the wm update calls are still done through the legacy
functions.
This will make it easier to bisect things if they go wrong.
CI was having issues on the kms_cursor_legacy tests with too
much debug info printed out, in order to reduce
== Series Details ==
Series: drm/i915: Add has_psr-flag to gen9lp
URL : https://patchwork.freedesktop.org/series/28488/
State : failure
== Summary ==
Series 28488v1 drm/i915: Add has_psr-flag to gen9lp
https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/
Test
While testing Jim Bride's latest batch of PSR patches I noticed
that gen9lp doesn't include the has_psr flag, and that our GLK
system thus reported PSR as unsupported.
This patch simply adds has_psr.
Signed-off-by: David Weinehall
---
On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
>
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
>
> v2:
On 08/08/2017 12:55 PM, Arkadiusz Hiler wrote:
On Mon, Aug 07, 2017 at 03:23:29PM +0300, Petri Latvala wrote:
Signed-off-by: Petri Latvala
Reviewed-by: Arkadiusz Hiler
Thanks, pushed.
--
Petri Latvala
On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
>
> Signed-off-by: Daniel Vetter
[...]
> drivers/gpu/drm/sti/sti_cursor.c|
On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_connector_set_property.
>
> The only special case is nouveau which used one function for both
> pre-nv50 legacy modeset code and post-nv50
On Mon, Aug 07, 2017 at 03:23:29PM +0300, Petri Latvala wrote:
> Signed-off-by: Petri Latvala
Reviewed-by: Arkadiusz Hiler
--
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Tue, Aug 8, 2017 at 11:25 AM, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-08-08 10:01:59)
>> On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson
>> wrote:
>> > Quoting Daniel Vetter (2017-08-07 17:26:56)
>> >> On Fri, Aug 04, 2017 at
On Mon, 2017-08-07 at 10:42 +0200, Maarten Lankhorst wrote:
> Op 04-08-17 om 10:07 schreef Mika Kahola:
> >
> > On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote:
> > >
> > > With the conversion to atomic, this is already handled in the
> > > core.
> > >
> > > Signed-off-by: Maarten
Op 07-08-17 om 14:17 schreef Patchwork:
> == Series Details ==
>
> Series: drm/i915: Convert gen4- watermarks to atomic. (rev2)
> URL : https://patchwork.freedesktop.org/series/23954/
> State : failure
>
> == Summary ==
>
> Series 23954v2 drm/i915: Convert gen4- watermarks to atomic.
>
Quoting Daniel Vetter (2017-08-08 10:01:59)
> On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson wrote:
> > Quoting Daniel Vetter (2017-08-07 17:26:56)
> >> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote:
> >> > Quoting Daniel Vetter (2017-08-04 17:07:22)
> >> >
I screwed up:
- a '/' at the end makes readlink follow the link before testing it.
- only delete everything when it's not a symlink.
Cc: Jani Nikula
Acked-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
dim |
On Mon, Aug 7, 2017 at 6:34 PM, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-08-07 17:26:56)
>> On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote:
>> > Quoting Daniel Vetter (2017-08-04 17:07:22)
>> > > We now have full (or a lot at least) igt running in
On 8/7/2017 11:13 PM, Alex Williamson wrote:
> On Mon, 7 Aug 2017 08:11:43 +
> "Zhang, Tina" wrote:
>
>> After going through the previous discussions, here are some summaries may be
>> related to the current discussion:
>> 1. How does user mode figure the device
On Mon, 07 Aug 2017, Rodrigo Vivi wrote:
> good idea.
>
>
> On Mon, Aug 7, 2017 at 9:10 AM, Daniel Vetter wrote:
>> On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote:
>>
>>> + *
>>> + * For bit fields, define a _MASK and a _SHIFT macro. Define
On Mon, 07 Aug 2017, Daniel Vetter wrote:
> On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote:
>> This is not to try to force a new style; this is my interpretation of
>> what the most common existing style is.
>>
>> With hopes I don't need to answer so many questions
There's no reason to entirely wedge the gpu, for the minimal deadlock
bugfix we only need to unbreak/decouple the atomic commit from the gpu
reset. The simplest way to fix that is by replacing the
unconditional fence wait a the top of commit_tail by a wait which
completes either when the fences
Blocking in a worker is ok, that's what the unbound_wq is for. And it
unifies the paths between the blocking and nonblocking commit, giving
me just one path where I have to implement the deadlock avoidance
trickery in the next patch.
I first tried to implement the following patch without this
... using the biggest hammer we have. This is essentially a weaponized
version of the timeout-based wedging Chris added in
commit 36703e79a982c8ce5a8e43833291f2719e92d0d1
Author: Chris Wilson
Date: Thu Jun 22 11:56:25 2017 +0100
drm/i915: Break modeset deadlocks
Thanks Clinton!
If you add:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100047
You have my Rb.
/Marta
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of clinton.a.tay...@intel.com
> Sent: Friday, August 4, 2017 9:23 PM
> To:
91 matches
Mail list logo