== Series Details ==
Series: drm/i915/psr : Add psr1 live status (rev5)
URL : https://patchwork.freedesktop.org/series/42021/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4237 -> Patchwork_9115 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://pa
On Thu, 24 May 2018, Joe Perches wrote:
> On Fri, 2018-05-25 at 09:41 +0300, Jani Nikula wrote:
>> On Thu, 24 May 2018, Joe Perches wrote:
>> > There is currently a mixture of octal and symbolic permissions uses
>> > in files in drivers/gpu/drm and one file in drivers/gpu.
>> >
>> > There are ~2
== Series Details ==
Series: drm/i915/psr: Set idle frame count based on sink synchronization latency
URL : https://patchwork.freedesktop.org/series/43742/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4236_full -> Patchwork_9113_full =
== Summary - WARNING ==
Minor unkn
On 24/05/2018 17:13, Lionel Landwerlin wrote:
On 24/05/18 17:07, Tvrtko Ursulin wrote:
On 24/05/2018 16:53, Lionel Landwerlin wrote:
On 24/05/18 16:04, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of using the engine->id, use uabi_class:instance pairs in
trace-
points including eng
On Thu, 24 May 2018, Dhinakaran Pandiyan wrote:
> DPCD 2009h "Synchronization latency in sink" has bits that tell us the
> maximum number of frames sink can take to resynchronize to source timing
> when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
> number of frames followi
== Series Details ==
Series: drm/i915: Prepare GEM for suspend earlier (rev4)
URL : https://patchwork.freedesktop.org/series/43575/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4237 -> Patchwork_9116 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_
Quoting Tvrtko Ursulin (2018-05-25 08:11:41)
>
> On 24/05/2018 17:13, Lionel Landwerlin wrote:
> > On 24/05/18 17:07, Tvrtko Ursulin wrote:
> >>
> >> On 24/05/2018 16:53, Lionel Landwerlin wrote:
> >>> On 24/05/18 16:04, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of u
Recently we discovered that we have a race between swapping and
suspend in our resume path (we might be trying to page in an object
after disabling the block devices). Let's try to exercise that by
exhausting all of system memory before suspend.
v2: Explicitly share the large memory area on forkin
On Thu, 24 May 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix up a bunch of bad indentation and insconsistent comments
> in edid_cea_modes[].
>
> v2: Instead of stripping the aspect ratio comments let's
> add them to all modes
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nik
Hi Jani,
I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the
brightness value of the display. I also did a test, when I disconnect the DP to
the display and execute the dd commands, it would say error reading
'dev/drm_dp_aux1': Connection timed out. So I think my displ
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together for redability.
Binary records are left as is, that is both fields remaing under the
existing name a
From: Tvrtko Ursulin
Instead of using the engine->id, use uabi_class:instance pairs in trace-
points including engine info.
This will be more readable, more future proof and more stable for
userspace consumption.
v2:
* Use u16 for class and instance. (Chris Wilson)
Signed-off-by: Tvrtko Ursul
From: Tvrtko Ursulin
Underlaying field is u64 so the tracepoint needs to be as well.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_trace.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
== Series Details ==
Series: drm/i915/psr : Add psr1 live status (rev5)
URL : https://patchwork.freedesktop.org/series/42021/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4237_full -> Patchwork_9115_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchw
On 24/05/2018 17:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-24 16:48:45)
On 24/05/2018 16:33, Chris Wilson wrote:
But what we call ctx here isn't really context, but timeline; how about
if we switch to the fence=%llx:%d representation we've mostly settled on
for the debug message
On Fri, 25 May 2018, John Sledge wrote:
> Hi Jani,
> I seek 0-800 and here's what I get, all 11 0A in hex. Not sure if this is the
> brightness value of the display. I also did a test, when I disconnect the DP
> to the display and execute the dd commands, it would say error reading
> 'dev/drm_
On 24/05/2018 14:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-24 14:34:41)
On 19/05/2018 10:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 15:42:00)
On 18/05/2018 15:13, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 13:36:52)
On 18/05/2018 13:28, Chris Wil
Quoting Tvrtko Ursulin (2018-05-25 09:30:29)
>
> On 24/05/2018 17:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-24 16:48:45)
> >>
> >> On 24/05/2018 16:33, Chris Wilson wrote:
> >>> But what we call ctx here isn't really context, but timeline; how about
> >>> if we switch to the fenc
Hello everyone,
I am new to DRM and linux, I started reading developers guide and research
on my own.
I don't know where to start on how to communicate the DP helper functions
(drm_dp_dpcd_read, drm_dp_dpcd_readb, drm_dp_dpcd_write,
drm_dp_dpcd_writeb),
what will I include(#include) in my main
Quoting Tvrtko Ursulin (2018-05-25 09:26:42)
> From: Tvrtko Ursulin
>
> Underlaying field is u64 so the tracepoint needs to be as well.
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_trace.h | 20 ++--
> 1 file changed, 10 inse
== Series Details ==
Series: series starting with [1/3] drm/i915/trace: Describe engines as
class:instance pairs
URL : https://patchwork.freedesktop.org/series/43763/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4238 -> Patchwork_9117 =
== Summary - WARNING ==
Minor un
== Series Details ==
Series: drm/i915: Prepare GEM for suspend earlier (rev4)
URL : https://patchwork.freedesktop.org/series/43575/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4237_full -> Patchwork_9116_full =
== Summary - FAILURE ==
Serious unknown changes coming wit
In order to prepare the GPU for sleeping, we may want to submit commands
to it. This is a complicated process that may even require some swapping
in from shmemfs, if the GPU was in the wrong state. As such, we need to
do this preparation step synchronously before the rest of the system has
started
== Series Details ==
Series: series starting with drm/i915/gtt: Avoid calling non-existent
allocate_va_range (rev2)
URL : https://patchwork.freedesktop.org/series/42448/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4238 -> Patchwork_9118 =
== Summary - FAILURE ==
Serio
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been reset
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4
The series is still in flux as we depend on getting the bug fixes
resolved at the head of the series first. But I wanted to present this
before the w/e so you all have some reading material!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 24 +++
We can avoid the mmio read of the CSB pointers after reset based on the
knowledge that the HW always start writing at entry 0 in the CSB buffer.
We need to reset our CSB head tracking after GPU reset (and on
sanitization after resume) so that we are expecting to read from entry
0.
Signed-off-by: C
In the next patch, we will begin processing the CSB from inside the
interrupt handler. This means that updating the execlists->port[] will
no longer be locked by the tasklet but by the engine->timeline.lock
instead. Pull dequeue and submit under the same lock for protection.
(An alternative, future
In the following patch, we will process the CSB interrupt under the
timeline.lock and not under the tasklet lock. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on av
In order to prepare the GPU for sleeping, we may want to submit commands
to it. This is a complicated process that may even require some swapping
in from shmemfs, if the GPU was in the wrong state. As such, we need to
do this preparation step synchronously before the rest of the system has
started
In the next patch, we will move ownership of the fence reference to the
submission backend and will want to drop its final reference when
retiring it from the submission backend. We will also need a catch up
when parking the engine to cleanup any residual entries in the engine
timeline. In short, m
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.0
Our long standing defense against a single client from flooding the
system with requests (causing mempressure and stalls across the whole
system) is to retire the old request on every allocation. (By retiring
the oldest, we try to keep returning requests back to the system in a
steady flow.) This a
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can reduce
In the next patch, we will process the CSB events directly from the CS
interrupt handler, being called for each interrupt. Hence, we will no
longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
Signed-off-by: Chris Wilson
--
In the next patch, we will start to defer retiring the request from the
engine list if it is still active on the submission backend. To preserve
the semantics that after wait-for-idle completes the system is idle and
fully retired, we need to therefore wait for the backends to idle before
calling i
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is
After a reset, we will ensure that there is at least one request
submitted to HW to ensure that a context is loaded for powersaving.
Let's wait for this submission via a tasklet to complete before we drop
our forcewake, ensuring the system is ready for rc6 before we let it
possible sleep.
Signed-o
Currently the async submission backends (guc and execlists) hold a extra
reference to the requests being processed as they are not serialised with
request retirement. If we instead, prevent the request being dropped
from the engine timeline until after submission has finished processing
the request
== Series Details ==
Series: drm/i915: Prepare GEM for suspend earlier (rev5)
URL : https://patchwork.freedesktop.org/series/43575/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4238 -> Patchwork_9119 =
== Summary - SUCCESS ==
No regressions found.
External URL:
http
== Series Details ==
Series: series starting with [01/18] drm/i915: Prepare GEM for suspend earlier
URL : https://patchwork.freedesktop.org/series/43765/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f6ebcbc1316a drm/i915: Prepare GEM for suspend earlier
14c41b87a902 drm/i915:
== Series Details ==
Series: series starting with [01/18] drm/i915: Prepare GEM for suspend earlier
URL : https://patchwork.freedesktop.org/series/43765/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Prepare GEM for suspend earlier
Okay!
Commit: drm/i915: Switch
== Series Details ==
Series: series starting with [01/18] drm/i915: Prepare GEM for suspend earlier
URL : https://patchwork.freedesktop.org/series/43765/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4238 -> Patchwork_9120 =
== Summary - SUCCESS ==
No regressions found.
On 25/05/18 09:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of using the engine->id, use uabi_class:instance pairs in trace-
points including engine info.
This will be more readable, more future proof and more stable for
userspace consumption.
v2:
* Use u16 for class and instance.
On 25/05/18 09:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together for redability.
Binary records are left as is, that is bo
On 25/05/18 11:28, Lionel Landwerlin wrote:
On 25/05/18 09:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together for redabilit
On Fri, May 25, 2018 at 10:26:29AM +0100, Chris Wilson wrote:
> In order to prepare the GPU for sleeping, we may want to submit commands
> to it. This is a complicated process that may even require some swapping
> in from shmemfs, if the GPU was in the wrong state. As such, we need to
> do this pre
Quoting Ville Syrjälä (2018-05-25 11:51:13)
> On Fri, May 25, 2018 at 10:26:29AM +0100, Chris Wilson wrote:
> > In order to prepare the GPU for sleeping, we may want to submit commands
> > to it. This is a complicated process that may even require some swapping
> > in from shmemfs, if the GPU was i
On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required notifier registration.
v2:
mei interface handle is protected with mutex. [Chri
Dhinakaran Pandiyan writes:
> On Thu, 2018-05-24 at 12:22 +0300, Mika Kuoppala wrote:
>> Paulo Zanoni writes:
>>
>> >
>> > From: Dhinakaran Pandiyan
>> >
>> > The Graphics System Event(GSE) interrupt bit has a new location in
>> > the
>> > GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Si
On 25/05/2018 11:28, Lionel Landwerlin wrote:
On 25/05/18 09:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together for redabi
Recently we discovered that we have a race between swapping and
suspend in our resume path (we might be trying to page in an object
after disabling the block devices). Let's try to exercise that by
exhausting all of system memory before suspend.
v2: Explicitly share the large memory area on forkin
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
v4: rebased
v5: rebased, pulled out from the series
Signed-off-by: Michal Wajde
We are not nice parents and would sacrifice any one of our children so
that the core process can report the failure neatly.
Signed-off-by: Chris Wilson
---
lib/igt_core.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index
Chris Wilson writes:
> During suspend we want to flush out all active contexts and their
> rendering. To do so we queue a request from the kernel's context, once
> we know that request is done, we know the GPU is completely idle. To
> speed up that switch bump the GPU clocks.
>
> Switching to the
On 25/05/2018 13:13, Tvrtko Ursulin wrote:
On 25/05/2018 11:28, Lionel Landwerlin wrote:
On 25/05/18 09:26, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the t
Quoting Mika Kuoppala (2018-05-25 13:22:55)
> Chris Wilson writes:
>
> > During suspend we want to flush out all active contexts and their
> > rendering. To do so we queue a request from the kernel's context, once
> > we know that request is done, we know the GPU is completely idle. To
> > speed
Chris Wilson writes:
> After a reset, we will ensure that there is at least one request
> submitted to HW to ensure that a context is loaded for powersaving.
> Let's wait for this submission via a tasklet to complete before we drop
> our forcewake, ensuring the system is ready for rc6 before we l
Den 24.05.2018 11.16, skrev Daniel Vetter:
On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.
A t
Quoting Chris Wilson (2018-05-22 11:19:37)
> After a reset, we will ensure that there is at least one request
> submitted to HW to ensure that a context is loaded for powersaving.
> Let's wait for this submission via a tasklet to complete before we drop
> our forcewake, ensuring the system is ready
== Series Details ==
Series: drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
URL : https://patchwork.freedesktop.org/series/43770/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4238 -> Patchwork_9121 =
== Summary - SUCCESS ==
No regressions found.
External URL:
ht
Quoting Tvrtko Ursulin (2018-05-25 09:36:18)
>
> On 24/05/2018 14:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-24 14:34:41)
> >>
> >> On 19/05/2018 10:04, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-05-18 15:42:00)
>
> On 18/05/2018 15:13, Chris Wilson wrote:
>
== Series Details ==
Series: series starting with [1/3] drm/i915/trace: Describe engines as
class:instance pairs
URL : https://patchwork.freedesktop.org/series/43763/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9117_full =
== Summary - WARNING ==
Chris Wilson writes:
> In order to prepare the GPU for sleeping, we may want to submit commands
> to it. This is a complicated process that may even require some swapping
> in from shmemfs, if the GPU was in the wrong state. As such, we need to
> do this preparation step synchronously before the
Chris Wilson writes:
> As we reset the GPU on suspend/resume, we also do need to reset the
> engine state tracking so call into the engine backends. This is
> especially important so that we can also sanitize the state tracking
> across resume.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gp
Quoting Mika Kuoppala (2018-05-25 14:13:19)
> Chris Wilson writes:
>
> > As we reset the GPU on suspend/resume, we also do need to reset the
> > engine state tracking so call into the engine backends. This is
> > especially important so that we can also sanitize the state tracking
> > across resu
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-05-25 14:13:19)
>> Chris Wilson writes:
>>
>> > As we reset the GPU on suspend/resume, we also do need to reset the
>> > engine state tracking so call into the engine backends. This is
>> > especially important so that we can also sanitize the
== Series Details ==
Series: drm/i915: Prepare GEM for suspend earlier (rev5)
URL : https://patchwork.freedesktop.org/series/43575/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9119_full =
== Summary - WARNING ==
Minor unknown changes coming with
Chris Wilson writes:
> We can reduce our exposure to random neutrinos by resting on the kernel
> context having flushed out the user contexts to system memory and
> beyond. The corollary is that we then we require two passes through the
> idle handler to go to sleep, which on a truly idle system
Quoting Ville Syrjälä (2018-05-25 11:51:13)
> On Fri, May 25, 2018 at 10:26:29AM +0100, Chris Wilson wrote:
> > In order to prepare the GPU for sleeping, we may want to submit commands
> > to it. This is a complicated process that may even require some swapping
> > in from shmemfs, if the GPU was i
On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Fix up a bunch of bad indentation and insconsistent comments
inconsistent
With that fixed:
Reviewed-by: Alex Deucher
> in edid_cea_modes[].
>
> v2: Instead of stripping the aspect ratio comments let's
> add th
== Series Details ==
Series: series starting with [01/18] drm/i915: Prepare GEM for suspend earlier
URL : https://patchwork.freedesktop.org/series/43765/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4238_full -> Patchwork_9120_full =
== Summary - FAILURE ==
Serious unkn
On Fri, May 25, 2018 at 10:21:20AM -0400, Alex Deucher wrote:
> On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala
> wrote:
> > From: Ville Syrjälä
> >
> > Fix up a bunch of bad indentation and insconsistent comments
>
> inconsistent
Dang. Pulled the trigger on dim mere seconds before seeing your
r
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happen
On Thu, May 24, 2018 at 10:19:02PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-05-24 20:04:05)
> > From: Ville Syrjälä
> >
> > My ILK seems to generate a spurious PCH underrun with most interlaced
> > HDMI modes. Add a second vblank wait to avoid it.
>
> Fwiw, a second vblank becaus
On Fri, May 18, 2018 at 06:01:38PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> VBT seems to have some bits to tell us whether the internal LVDS port
> has something hooked up. In theory one might expect the VBT to not have
> a child device for the LVDS port if there's no panel hooked up
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!
Signed-
On Fri, 25 May 2018, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 10:19:02PM +0100, Chris Wilson wrote:
>> Quoting Ville Syrjala (2018-05-24 20:04:05)
>> > From: Ville Syrjälä
>> >
>> > My ILK seems to generate a spurious PCH underrun with most interlaced
>> > HDMI modes. Add a second vblank w
Quoting Ville Syrjala (2018-05-24 20:04:06)
> From: Ville Syrjälä
>
> Let's suppress the underruns around every modeset sequence instead
> of trying to avoid it. Planes are disabled at this point anyway so
> we don't really gain anything from keeping the underrun reporting
> enabled. Also for PCH
On 24/05/18 11:39, Tvrtko Ursulin wrote:
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -981,7 +981,8 @@ int i915_gem_context_setparam_ioctl(struct
drm_device *dev, void *data,
break;
}
- if (!capable(C
On Fri, May 25, 2018 at 04:20:07PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-05-24 20:04:06)
> > From: Ville Syrjälä
> >
> > Let's suppress the underruns around every modeset sequence instead
> > of trying to avoid it. Planes are disabled at this point anyway so
> > we don't really
On Fri, May 25, 2018 at 06:19:17PM +0300, Jani Nikula wrote:
> On Fri, 25 May 2018, Ville Syrjälä wrote:
> > On Thu, May 24, 2018 at 10:19:02PM +0100, Chris Wilson wrote:
> >> Quoting Ville Syrjala (2018-05-24 20:04:05)
> >> > From: Ville Syrjälä
> >> >
> >> > My ILK seems to generate a spurious
== Series Details ==
Series: drm/i915: Remove stale asserts from i915_gem_find_active_request()
URL : https://patchwork.freedesktop.org/series/43781/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4242 -> Patchwork_9122 =
== Summary - WARNING ==
Minor unknown changes comi
From: Mahesh Kumar
All connectors may not have best_encoder attached, so don't dereference
encoder pointer for each connector.
Fixes: c27e917e2bda (drm/i915/icl: add basic support for the ICL clocks)
Signed-off-by: Mahesh Kumar
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_ddi.c
Quoting Ville Syrjälä (2018-05-25 16:43:42)
> On Fri, May 25, 2018 at 04:20:07PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-05-24 20:04:06)
> > > From: Ville Syrjälä
> > >
> > > Let's suppress the underruns around every modeset sequence instead
> > > of trying to avoid it. Planes
Looks like the seek=%d in the sprintf is not working. 0x11 0x0A are being
returned by the monitor from DPCD’s 0x and 0x0001 repeatedly. The first is
DPCD revision (1.1) and the second is maximum Link Rate (0x0a) which is 2.7
Gbps. You might want to do a printf of call to make sure seek is be
On Thu, May 24, 2018 at 05:26:38PM -0700, Paulo Zanoni wrote:
> Em Seg, 2018-05-21 às 17:25 -0700, Paulo Zanoni escreveu:
> > From: Manasi Navare
> >
> > DFLEXDPMLE register is required to tell the FIA hardware which
> > main links of DP are enabled on TCC Connectors. FIA uses this
> > informatio
On Thu, May 24, 2018 at 05:36:37PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 04:42:36PM -0700, Paulo Zanoni wrote:
> > From: Mahesh Kumar
> >
> > ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/11/12
> > mapped to tc ports[1-4].
> > This patch defines GPIOCTL registe
On Fri, May 25, 2018 at 07:24:07PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 05:36:37PM -0700, Lucas De Marchi wrote:
> > On Thu, May 24, 2018 at 04:42:36PM -0700, Paulo Zanoni wrote:
> > > From: Mahesh Kumar
> > >
> > > ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/
On Mon, May 21, 2018 at 05:25:41PM -0700, Paulo Zanoni wrote:
> From: Manasi Navare
>
> This patch adds a proper HDMI DDI entry level for vswing
> programming sequences on ICL.
>
> Spec doesn't specify any default for HDMI tables,
> so let's pick the last entry as the default for now
> to stay c
== Series Details ==
Series: drm/i915/icl: fix icl_unmap/map_plls_to_ports (rev2)
URL : https://patchwork.freedesktop.org/series/43510/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4242 -> Patchwork_9123 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Fri, May 25, 2018 at 09:14:57AM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:26:38PM -0700, Paulo Zanoni wrote:
> > Em Seg, 2018-05-21 às 17:25 -0700, Paulo Zanoni escreveu:
> > > From: Manasi Navare
> > >
> > > DFLEXDPMLE register is required to tell the FIA hardware which
> > >
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
While using a single timestamp to compute the interval does not allow
very fine accuracy (consider the imp
On Fri, 25 May 2018, "Taylor, Clinton A" wrote:
> Looks like the seek=%d in the sprintf is not working.
Yeah. Try skip=%d instead.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On 25/05/2018 18:11, Chris Wilson wrote:
hrtimer is not reliable enough to assume fixed intervals, and so even
coarse accuracy (in the face of kasan and similar heavy debugging) we
need to measure the actual interval between sample.
It doesn't even average out to something acceptable under suc
Quoting Tvrtko Ursulin (2018-05-25 18:31:35)
>
> On 25/05/2018 18:11, Chris Wilson wrote:
> > hrtimer is not reliable enough to assume fixed intervals, and so even
> > coarse accuracy (in the face of kasan and similar heavy debugging) we
> > need to measure the actual interval between sample.
>
>
1 - 100 of 161 matches
Mail list logo
