== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev8)
URL : https://patchwork.freedesktop.org/series/25091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12743_full
Su
Quoting Takashi Iwai (2019-04-10 06:29:07)
> On Wed, 10 Apr 2019 00:53:31 +0200,
> Chris Wilson wrote:
> >
> > Quoting Takashi Iwai (2019-04-09 22:35:28)
> > > On Tue, 09 Apr 2019 23:27:41 +0200,
> > > Chris Wilson wrote:
> > > >
> > > > In runtime_resume, we release the local display_power waker
On Wed, 10 Apr 2019 09:59:19 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-10 06:29:07)
> > On Wed, 10 Apr 2019 00:53:31 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Takashi Iwai (2019-04-09 22:35:28)
> > > > On Tue, 09 Apr 2019 23:27:41 +0200,
> > > > Chris Wilson wrote:
> >
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-04-09 17:13:06)
>> Use a recommended idle hysteresis for media and render powergates.
>>
>> References: bspec#52070
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 delet
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-04-09 17:13:08)
>> There is no video turbo mode for gen11, so don't set it.
>>
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/g
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-04-09 17:13:09)
>> Unlike previous gens, we already hold the irq_lock on
>> entering the rps handler so we can't use it as it is.
>>
>> Make a gen11 specific rps interrupt handler without
>> locking.
>>
>> Signed-off-by: Mika Kuoppala
>> ---
>
While we only allow a single display power reference, the current
acquisition/release is racy and a direct call may run concurrently with
a runtime-pm worker. Prevent the double unreference by atomically
tracking the display_power_active cookie.
Testcase: igt/i915_pm_rpm/module-reload #glk-dsi
Sig
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-04-09 17:13:10)
>> With gen11 the interrupt registers are shared between 2 engines,
>> with Engine1 instance being upper word and Engine0 instance being
>> lower. Annoyingly gen11 selected the pm interrupts to be in the
>> Engine1 instance.
>
> S
Quoting Chris Wilson (2019-04-10 09:17:33)
> While we only allow a single display power reference, the current
> acquisition/release is racy and a direct call may run concurrently with
> a runtime-pm worker. Prevent the double unreference by atomically
> tracking the display_power_active cookie.
I
== Series Details ==
Series: drm/i915: Avoiding reclaim tainting from runtime-pm debug
URL : https://patchwork.freedesktop.org/series/59242/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12744_full
Su
On 09/04/2019 18:49, Wysocki, Rafael J wrote:
> On 4/9/2019 8:29 AM, Anshuman Gupta wrote:
>> There were few system hung observed while running i915_pm_rpm igt test.
>> FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
>> Root cause is believed to due to page fault in ACPI idle driver.
>> (FD
From: Alastair D'Silva
> Sent: 10 April 2019 04:17
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of by
Quoting Patchwork (2019-04-10 06:59:20)
> Possible fixes
>
> * igt@i915_pm_rps@reset:
> - shard-iclb: FAIL [fdo#108059] -> PASS +2
\o/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.or
== Series Details ==
Series: snd/hda: Only get/put display_power once
URL : https://patchwork.freedesktop.org/series/59267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5897 -> Patchwork_12749
Summary
---
**SUCCESS*
On 08/04/2019 10:17, Chris Wilson wrote:
On resume, we know that the only pinned contexts in danger of seeing
corruption are the kernel context, and so we do not need to walk the
list of all GEM contexts as we tracked them on each engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
On 08/04/2019 10:17, Chris Wilson wrote:
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. This first/last access needs serialisation and so
we encompass a mutex with the regular in
On 08/04/2019 10:17, Chris Wilson wrote:
Split out the powermanagement portion (GT wakeref, suspend/resume) of
GEM from i915_gem.c into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/Makefile.header-test | 1 +
Quoting Tvrtko Ursulin (2019-04-10 10:49:35)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > For controlling runtime pm of the GT and engines, we would like to have
> > a callback to do extra work the first time we wake up and the last time
> > we drop the wakeref. This first/last access needs se
On 08/04/2019 10:17, Chris Wilson wrote:
We wish to start segregating the power management into different control
domains, both with respect to the hardware and the user interface. The
first step is that at the lowest level flow of requests, we want to
process a context event (and not a global G
On 10/04/2019 11:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-10 10:49:35)
On 08/04/2019 10:17, Chris Wilson wrote:
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. T
On Wed, 10 Apr 2019 10:17:33 +0200,
Chris Wilson wrote:
>
> While we only allow a single display power reference, the current
> acquisition/release is racy and a direct call may run concurrently with
> a runtime-pm worker. Prevent the double unreference by atomically
> tracking the display_power_a
Hi Ville,
From Intel BSpec, this is HDMI max data rate bits field definition as the
following, and please find my experiment/log below. And as I knew, all
platforms are using Default 000 for max data rate. (No any platform used
2.97/1.65 definition in VBT so far). That’s why I correct HDMI ma
Quoting Tvrtko Ursulin (2019-04-10 11:05:13)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > +void __intel_context_enter(struct intel_context *ce)
> > +{
> > + struct drm_i915_private *i915 = ce->gem_context->i915;
> > +
> > + if (!i915->gt.active_requests++)
> > + i915_gem_un
Quoting Takashi Iwai (2019-04-10 11:09:47)
> On Wed, 10 Apr 2019 10:17:33 +0200,
> Chris Wilson wrote:
> >
> > While we only allow a single display power reference, the current
> > acquisition/release is racy and a direct call may run concurrently with
> > a runtime-pm worker. Prevent the double u
On Tue, Apr 09, 2019 at 10:16:04PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-09 15:40:48)
> > From: Ville Syrjälä
> >
> > The AVI infoframe readout code currently issues a
> > SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is
> > not the correct order for these t
On 08/04/2019 10:17, Chris Wilson wrote:
Start acquiring the logical intel_context and using that as our primary
means for request allocation. This is the initial step to allow us to
avoid requiring struct_mutex for request allocation along the
perma-pinned kernel context, but it also provides a
== Series Details ==
Series: snd/hda: Only get/put display_power once (rev2)
URL : https://patchwork.freedesktop.org/series/59267/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
156ac646b015 snd/hda: Only get/put display_power once
-:76: ERROR:MISSING_SIGN_OFF: Missing Signed-of
On Wed, 10 Apr 2019 12:24:24 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-10 11:09:47)
> > On Wed, 10 Apr 2019 10:17:33 +0200,
> > Chris Wilson wrote:
> > >
> > > While we only allow a single display power reference, the current
> > > acquisition/release is racy and a direct call
On Wed, Apr 10, 2019 at 10:08:43AM +, Chiou, Cooper wrote:
> Hi Ville,
>
>
>
> From Intel BSpec, this is HDMI max data rate bits field definition as the
> following, and please find my experiment/log below. And as I knew, all
> platforms are using Default 000 for max data rate. (No any pla
== Series Details ==
Series: drm/i915: Fix setting 10 bit color mode
URL : https://patchwork.freedesktop.org/series/59246/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12745_full
Summary
---
*
There is no video turbo mode for gen11, so don't set it.
v2: inline (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
in
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
v2: return early (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i
On gen11 the recommended rc6 threshold differs from previous
gens, apply it. Move the write to a correct spot in sequence.
v2: do write in 2b, fix bspec ref (Michal)
Bspec: 33149
Cc: Michal Wajdeczko
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 i
Enable media sampler powergate as recommended.
v2: use REG_BIT (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915
There is a chance we can see spurious interrupts in live
now. We have more engines enabled and that with more elaborate
access patterns with pm and display, increases the chances
hardware just makes a social call, without anything to work on.
Remove the error as we have tests to actually probe if
With gen11 the interrupt registers are shared between 2 engines,
with Engine1 instance being upper word and Engine0 instance being
lower. Annoyingly gen11 selected the pm interrupts to be in the
Engine1 instance.
Rectify the situation by shifting the access accordingly,
based on gen.
v2: comments
In order not to inflate gen9 rc6 enabling sequence with
gen11 specifics, use a separate function for it.
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_pm.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/
On Wed, 10 Apr 2019 12:44:49 +0200,
Takashi Iwai wrote:
>
> On Wed, 10 Apr 2019 12:24:24 +0200,
> Chris Wilson wrote:
> >
> > Quoting Takashi Iwai (2019-04-10 11:09:47)
> > > On Wed, 10 Apr 2019 10:17:33 +0200,
> > > Chris Wilson wrote:
> > > >
> > > > While we only allow a single display power
Quoting Mika Kuoppala (2019-04-10 11:59:20)
> There is no video turbo mode for gen11, so don't set it.
>
> v2: inline (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
On 10/04/2019 11:13, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-10 11:05:13)
On 08/04/2019 10:17, Chris Wilson wrote:
+void __intel_context_enter(struct intel_context *ce)
+{
+ struct drm_i915_private *i915 = ce->gem_context->i915;
+
+ if (!i915->gt.active_requests++)
+
Quoting Mika Kuoppala (2019-04-10 11:59:23)
> There is a chance we can see spurious interrupts in live
> now. We have more engines enabled and that with more elaborate
> access patterns with pm and display, increases the chances
> hardware just makes a social call, without anything to work on.
>
>
== Series Details ==
Series: snd/hda: Only get/put display_power once (rev2)
URL : https://patchwork.freedesktop.org/series/59267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5898 -> Patchwork_12750
Summary
---
**S
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11
URL : https://patchwork.freedesktop.org/series/59278/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0c869cb6edc4 drm/i915: Use dedicated rc6 enabling sequence for ge
On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote:
> The function __kms_addfb() and drmModeAddFB2WithModifiers() have a
> similar code. Due to this similarity, this commit replace part of the
> code inside __kms_addfb() by using drmModeAddFB2WithModifiers().
igt master % grep '^libd
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11
URL : https://patchwork.freedesktop.org/series/59278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5898 -> Patchwork_12751
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
Signed-off-by: Thomas Gleixner
Cc: intel-gfx@lists.freedesktop.org
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: dri-de...@lists.freedesktop.org
Cc: David Airlie
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rodrigo
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries po
Quoting Arkadiusz Hiler (2019-04-10 12:28:08)
> On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote:
> > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a
> > similar code. Due to this similarity, this commit replace part of the
> > code inside __kms_addfb() by using d
From: Tvrtko Ursulin
Some displays might not support hardcoded 1024x768.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109294
---
tests/prime_vgem.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tests/prime_vgem
Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
> @@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem, unsigned hang)
> uint32_t offsets[4] = {};
> int fd;
>
> - bo[i].width = 1024;
> - bo[i].height = 768;
> + bo[i].w
On Wed, Apr 10, 2019 at 12:34:07PM +0100, Chris Wilson wrote:
> Quoting Arkadiusz Hiler (2019-04-10 12:28:08)
> > On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote:
> > > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a
> > > similar code. Due to this similarity, th
Quoting Arkadiusz Hiler (2019-04-10 12:57:03)
> On Wed, Apr 10, 2019 at 12:34:07PM +0100, Chris Wilson wrote:
> > Quoting Arkadiusz Hiler (2019-04-10 12:28:08)
> > > On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote:
> > > > The function __kms_addfb() and drmModeAddFB2WithModifiers()
On 08/04/2019 10:17, Chris Wilson wrote:
We want to pass in a intel_context into intel_context_pin() and that
requires us to first be able to lookup the intel_context!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c| 37 +++---
drivers/gpu/drm/i91
On 10/04/2019 12:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
@@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem, unsigned hang)
uint32_t offsets[4] = {};
int fd;
- bo[i].width = 1024;
- bo[i].he
On Wed, Apr 10, 2019 at 11:32:47AM +, Chiou, Cooper wrote:
> Hi Ville,
>
>
>
> From BSpec define, HDMI max data rate is “Bits 5-7” not Bits 4-7. And the
> following image is what I captured by latest VBT BMP v2.67 tool to load GLK
> VBT bin file and changed HDMI_MAX_TMDS_Bit_Rate field in
On 08/04/2019 10:17, Chris Wilson wrote:
Combine the (i915_gem_context, intel_engine) into a single parameter,
the intel_context for convenience and later simplification.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 74 +++
1 file changed,
== Series Details ==
Series: snd/hda: Only get/put display_power once
URL : https://patchwork.freedesktop.org/series/59267/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12749_full
Summary
---
== Series Details ==
Series: snd/hda: Only get/put display_power once (rev3)
URL : https://patchwork.freedesktop.org/series/59267/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
95d66eed4e0b snd/hda: Only get/put display_power once
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible un
On 08/04/2019 10:17, Chris Wilson wrote:
Move the intel_context_instance() to the caller so that we can decouple
ourselves from one context instance per engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 26 --
drivers/gpu/drm/i915/gt/intel_context.h
Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index da342e9a8c2e..4f8ef45e6344 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/
On Fri, 05 Apr 2019, Rodrigo Vivi wrote:
> On Fri, Apr 05, 2019 at 10:52:20AM +0300, Jani Nikula wrote:
>> Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
>> and narrow") started to optize the eDP 1.4+ link config, both per spec
>> and as preparation for display stream compre
== Series Details ==
Series: snd/hda: Only get/put display_power once (rev3)
URL : https://patchwork.freedesktop.org/series/59267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5898 -> Patchwork_12752
Summary
---
**S
Quoting Chris Wilson (2019-04-10 13:49:32)
> Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
> >
> > On 08/04/2019 10:17, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index da342e9a8c2e..4f8ef45e6344 100644
> > >
Quoting Takashi Iwai (2019-04-10 12:03:22)
> On Wed, 10 Apr 2019 12:44:49 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 10 Apr 2019 12:24:24 +0200,
> > Chris Wilson wrote:
> > >
> > > Quoting Takashi Iwai (2019-04-10 11:09:47)
> > > > On Wed, 10 Apr 2019 10:17:33 +0200,
> > > > Chris Wilson wrote:
There is a chance we can see spurious interrupts in live
now. We have more engines enabled and that with more elaborate
access patterns with pm and display, increases the chances
hardware just makes a social call, without anything to work on.
Remove the error as we have tests to actually probe if
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Monday, April 8, 2019 9:38 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.or
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
v2: return early (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i
On Wed, 10 Apr 2019 15:07:28 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2019-04-10 12:03:22)
> > On Wed, 10 Apr 2019 12:44:49 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 10 Apr 2019 12:24:24 +0200,
> > > Chris Wilson wrote:
> > > >
> > > > Quoting Takashi Iwai (2019-04-10 11:09:
There is no video turbo mode for gen11, so don't set it.
v2: inline (Chris)
v3: brackets (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/d
On 08/04/2019 10:17, Chris Wilson wrote:
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h
Quoting Mika Kuoppala (2019-04-10 11:59:18)
> On gen11 the recommended rc6 threshold differs from previous
> gens, apply it. Move the write to a correct spot in sequence.
>
> v2: do write in 2b, fix bspec ref (Michal)
Yes, it does make more sense not to include it as part of the 'rc6
enabling seq
Quoting Mika Kuoppala (2019-04-10 11:59:19)
> Enable media sampler powergate as recommended.
>
> v2: use REG_BIT (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.free
Quoting Mika Kuoppala (2019-04-10 11:59:22)
> With gen11 the interrupt registers are shared between 2 engines,
> with Engine1 instance being upper word and Engine0 instance being
> lower. Annoyingly gen11 selected the pm interrupts to be in the
> Engine1 instance.
>
> Rectify the situation by shif
Quoting Mika Kuoppala (2019-04-10 14:24:36)
> There is no video turbo mode for gen11, so don't set it.
>
> v2: inline (Chris)
> v3: brackets (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mail
On Wed, 10 Apr 2019 12:59:18 +0200, Mika Kuoppala
wrote:
On gen11 the recommended rc6 threshold differs from previous
gens, apply it. Move the write to a correct spot in sequence.
v2: do write in 2b, fix bspec ref (Michal)
Bspec: 33149
Cc: Michal Wajdeczko
Signed-off-by: Mika Kuoppala
F
The locks (timeline->lock and rq->lock) need to be taken with disabled
interrupts. This is done in __retire_engine_request() by disabling the
interrupts independently of the locks itself.
While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla
it does not on RT. Also, it is not obvi
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts
without irq lock
URL : https://patchwork.freedesktop.org/series/59288/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12753
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11 (rev2)
URL : https://patchwork.freedesktop.org/series/59278/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b962927fa121 drm/i915: Use dedicated rc6 enabling sequence
Chris Wilson writes:
> During reset, we try and stop the active ring. This has the consequence
> that we often clobber the RING registers within the context image. When
> we find an active request, we update the context image to rerun that
> request (if it was guilty, we replace the hanging user
Quoting Mika Kuoppala (2019-04-10 15:40:13)
> Chris Wilson writes:
> > /* Rerun the request; its payload has been neutered (if guilty). */
> > - rq->ring->head = intel_ring_wrap(rq->ring, rq->head);
> > - intel_ring_update_space(rq->ring);
> > +out_replay:
> > + ce->ring->head =
On 10/04/2019 14:04, Chris Wilson wrote:
Quoting Chris Wilson (2019-04-10 13:49:32)
Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
On 08/04/2019 10:17, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index da342e9a8c2e..4f8ef4
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11
URL : https://patchwork.freedesktop.org/series/59278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5898_full -> Patchwork_12751_full
==
== Series Details ==
Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling
sequence for gen11 (rev2)
URL : https://patchwork.freedesktop.org/series/59278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12754
=
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj
== Series Details ==
Series: drm/i915: Don't disable interrupts independently of the lock
URL : https://patchwork.freedesktop.org/series/59289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12755
Summary
-
On 08/04/2019 10:17, Chris Wilson wrote:
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW
On Wed, Apr 10, 2019 at 01:20:44PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Monday, April 8, 2019 9:38 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; intel-gf
Quoting Tvrtko Ursulin (2019-04-10 16:32:18)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 3f794bc71958..0df3c5238c04 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >
On Wed, 2019-04-10 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the
> rest
> is padded (typically with 0x00 or 0xff).
>
This patch introduces flags which allow lines of padding bytes to be
> suppressed, mak
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6 --
drive
From: Alastair D'Silva
With modern high resolution screens, we can display more data, which makes
life a bit easier when debugging.
Allow 64 bytes to be dumped per line.
Signed-off-by: Alastair D'Silva
---
lib/hexdump.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
dif
Nice, do you have any sample code for it?
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Ville Syrjälä
Sent: Tuesday, April 9, 2019 8:57 AM
To: Jim Zhang
Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: Re: [Intel-gfx] colorkey supp
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces flags which allow lines of padding bytes to be
suppressed, making the output easier to interpret: HEXDUMP_SUPPRESS_0X00,
HEXDUMP_SUPPRE
What about if I disable interrupt when changing the colorkey? This will solve
the atomic issue. I think we only change colorkey or enable/disable colorkey
once a while. If disabling interrupt work, I will disable interrupt and change
colorkey. That performance affection could be acceptable
Th
Ville:
Yes, if this patch is needed by kernel 3.10.61, please get somebody to review
it. What do I need do to speed up the review process?
Please generate a patch against kernel 3.10.61 if possible.
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Jim Zhang
Sen
If I go with pre-configured colorkey, do I need port your kernel patch to i915
driver at kernel 3.10.61 ?
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Ville Syrjälä
Sent: Tuesday, April 9, 2019 10:02 AM
To: Jim Zhang
Cc: intel-gfx@lists.freedesktop.org; dri
Once I pre-configure the colorkey, am I able to enable and disable it? If
colorkey can be enabled/disabled after that might meet my requirement
Thanks,
Jim
Caterpillar: Confidential Green
-Original Message-
From: Ville Syrjälä
Sent: Tuesday, April 9, 2019 8:57 AM
To: Jim Zhang
Cc:
> -Original Message-
> From: David Laight
> Sent: Wednesday, 10 April 2019 6:45 PM
> To: 'Alastair D'Silva' ; alast...@d-silva.org
> Cc: Jani Nikula ; Joonas Lahtinen
> ; Rodrigo Vivi ;
> David Airlie ; Daniel Vetter ; Karsten Keil
> ; Jassi Brar ; Tom Lendacky
> ; David S. Miller ;
> Jose
From: Alastair D'Silva
With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.
The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.
eg.
buf:: 454d414e 434
1 - 100 of 149 matches
Mail list logo
