Den 29.01.2019 01.19, skrev Eric Anholt:
> Noralf Trønnes writes:
>
>> Den 28.01.2019 21.57, skrev Rob Herring:
>>> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
Den 30.11.2018 00.58, skrev Eric Anholt:
> Daniel Vetter writes:
>
>> On Wed, Nov 28, 2018 at 01:
On Fri, Jan 25, 2019 at 11:01:48PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 10:39:38AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Use ENOENT consistently for the case where the requested propert
Present the latency results in nanoseconds not RCS cycles.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 38 +++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_latency.c b/tests/i915/gem_exec_latency.c
index de
Build a chain using 2 contexts (A, B) then request a preemption such
that a later A request runs before the spinner in B.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 103 +
1 file changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/s
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that even if we miss an
interrupt for a fence, it
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritative. As we only track the
maximum priority see
== Series Details ==
Series: series starting with [1/8] drm/i915: Rename execlists->queue_priority
to preempt_priority_hint
URL : https://patchwork.freedesktop.org/series/55886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a7e07cfaf594 drm/i915: Rename execlists->queue_priori
== Series Details ==
Series: series starting with [1/8] drm/i915: Rename execlists->queue_priority
to preempt_priority_hint
URL : https://patchwork.freedesktop.org/series/55886/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Rename execlists
Hi,
On 25-01-19 09:36, Hans de Goede wrote:
Hi Rodrigo and Maarten,
On 24-01-19 23:20, Rodrigo Vivi wrote:
On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
From: Hans de Goede
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Rather
Present the latency results in nanoseconds not RCS cycles.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 38 +++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_latency.c b/tests/i915/gem_exec_latency.c
index de
The first dispatch incurs the cost of waking up the device, so also
measure after issuing a spinner to keep the device awake as we submit.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/tests/
== Series Details ==
Series: series starting with [1/8] drm/i915: Rename execlists->queue_priority
to preempt_priority_hint
URL : https://patchwork.freedesktop.org/series/55886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5499 -> Patchwork_12065
On Fri, Jan 25, 2019 at 03:02:46PM +, Emil Velikov wrote:
> On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote:
> >
> > It's 0.
> >
> I'd add a bit more information here. Feel free to reuse as much/little
> of the following:
>
> Both macros evaluate to 0. At the same time flag is already set t
Quoting Michael Sartain (2019-01-29 01:52:12)
> On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote:
> > Rather than every backend and GPU driver reinventing the same wheel for
> > user level debugging of HW execution, the common dma-fence framework
> > should include the tracing infrastructure re
On 29/01/2019 08:58, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing cont
On 29/01/2019 08:58, Chris Wilson wrote:
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritativ
Quoting Tvrtko Ursulin (2019-01-29 10:13:47)
>
> On 29/01/2019 08:58, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/selftests/intel_lrc.c
> > b/drivers/gpu/drm/i915/selftests/intel_lrc.c
> > index 2b2ecd76c2ac..58f534a39118 100644
> > --- a/drivers/gpu/drm/i915/selftests/intel_lrc.c
>
Quoting Tvrtko Ursulin (2019-01-29 10:14:45)
>
> On 29/01/2019 08:58, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index 2927b712b973..5e2231d0c2fa 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/
Quoting Chris Wilson (2019-01-25 04:29:39)
> In bringup on simulated HW even rudimentary tests are slow, and so many
> may fail that we want to be able to filter out the noise to focus on the
> specific problem. Even just the tests groups provided for igt is not
> specific enough, and we would like
On 29/01/2019 10:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-29 10:14:45)
On 29/01/2019 08:58, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2927b712b973..5e2231d0c2fa 100644
--- a/drivers/gpu/drm/i915/int
And move the documenation we alreay have into kerneldoc, plus a bit of
polish while at it.
v2:
- Ditch FIXME from commit message, I've resolved that already before
sending out the first version.
- Put the legacy DRIVER_ flags at the end (Sam).
Cc: Sam Ravnborg
Reviewed-by: Emil Velikov
Review
If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers,
which control IRQ enabling/disabling through the DRM_IOCTL_CONTROL
legacy IOCTL.
Also remove all the flag usage from non-legacy drivers.
v2: Review from Emil:
- i
This is only used by drm_irq_install(), which is an optional helper.
For legacy pci devices this is required (due to interrupt sharing without
msi/msi-x), and just making this the default exactly matches the behaviour
of all existing drivers using the drm_irq_install() helpers. In case that
ever be
Build a chain using 2 contexts (A, B) then request a preemption such
that a later A request runs before the spinner in B.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 103 +
1 file changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/s
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritative. As we only track the
maximum priority see
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably su
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that even if we miss an
interrupt for a fence, it
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915
On 29/01/2019 08:58, Chris Wilson wrote:
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing
On 29/01/2019 10:59, Chris Wilson wrote:
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritativ
== Series Details ==
Series: series starting with [1/3] drm/irq: Don't check for DRIVER_HAVE_IRQ in
drm_irq_(un)install
URL : https://patchwork.freedesktop.org/series/55894/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a67d66ba546b drm/irq: Don't check for DRIVER_HAVE_IRQ in
Quoting Tvrtko Ursulin (2019-01-29 11:15:35)
>
> On 29/01/2019 08:58, Chris Wilson wrote:
> > On unwinding the active request we give it a small (limited to internal
> > priority levels) boost to prevent it from being gazumped a second time.
> > However, this means that it can be promoted to above
On 29/01/2019 10:59, Chris Wilson wrote:
Build a chain using 2 contexts (A, B) then request a preemption such
that a later A request runs before the spinner in B.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 103 +
1 file changed, 103 inse
igt_sysfs_get() only returns NULL if the open() fails, and a valid
string otherwise. So if the read() fails with ENODEV (because sysfs
doesn't provide the driver with an ->open() callback), we return an
empty string, and "No error captured" otherwise.
Bugzilla: https://bugs.freedesktop.org/show_bu
== Series Details ==
Series: series starting with [1/8] drm/i915: Rename execlists->queue_priority
to preempt_priority_hint
URL : https://patchwork.freedesktop.org/series/55886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5499_full -> Patchwork_12065_full
==
== Series Details ==
Series: series starting with [1/3] drm/irq: Don't check for DRIVER_HAVE_IRQ in
drm_irq_(un)install
URL : https://patchwork.freedesktop.org/series/55894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5500 -> Patchwork_12066
Quoting Lyude Paul (2019-01-28 20:56:01)
> When resuming, we check whether or not any previously connected
> MST topologies are still present and if so, attempt to resume them. If
> this fails, we disable said MST topologies and fire off a hotplug event
> so that userspace knows to reprobe.
>
> Ho
== Series Details ==
Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter
URL : https://patchwork.freedesktop.org/series/55898/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0d4c4d8eb25c drm/i915/selftests: Apply a subtest filter
efb75284d748 drm/i915:
== Series Details ==
Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter
URL : https://patchwork.freedesktop.org/series/55898/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/selftests: Apply a subtest filter
Okay!
Co
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> Create a new connector property to program colorspace to sink devices.
> Modern sink devices support more than 1 type of colorspace like 601,
> 709, BT2020 etc. This helps to switch based on content type which is
> to be displayed. The decision lies wit
== Series Details ==
Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter
URL : https://patchwork.freedesktop.org/series/55898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5500 -> Patchwork_12067
Quoting Tvrtko Ursulin (2019-01-29 12:26:46)
>
> On 29/01/2019 11:21, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-29 11:15:35)
> >>
> >> On 29/01/2019 08:58, Chris Wilson wrote:
> >>> On unwinding the active request we give it a small (limited to internal
> >>> priority levels) boost t
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate colorspace.
On 29/01/2019 11:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-29 11:15:35)
On 29/01/2019 08:58, Chris Wilson wrote:
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means th
Enabling FBC on a plane which has a combination of a 180-degree rotation
with having a Height that isn't divisible by 4 causes FIFO underrun,
so disable FBC on such a config.
Testcase: igt/kms_rotation_crc/multiplane-rotation-cropping-top
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1056
== Series Details ==
Series: drm/i915/gen9: Disable FBC on planes which have an unsupported config.
URL : https://patchwork.freedesktop.org/series/55900/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b49fb04454cb drm/i915/gen9: Disable FBC on planes which have an unsupported
c
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:54 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 1
We've supported the opregion RVDA/RVDS fields for VBT size >= 6 KB since
commit 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
KB"). That's three years, almost to the date.
The implementation was based on spec only, in anticipation of systems
with big VBT. Now, the spec has been
== Series Details ==
Series: drm/i915/gen9: Disable FBC on planes which have an unsupported config.
URL : https://patchwork.freedesktop.org/series/55900/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5500 -> Patchwork_12068
== Series Details ==
Series: drm/i915/opregion: rvda is relative from opregion base, not absolute
(rev2)
URL : https://patchwork.freedesktop.org/series/53996/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5500 -> Patchwork_12069
===
Quoting Hans de Goede (2019-01-25 10:36:48)
> Hi Rodrigo and Maarten,
>
> On 24-01-19 23:20, Rodrigo Vivi wrote:
> > On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
> >> From: Hans de Goede
> >>
> >> We really want to have fastboot enabled by default to avoid an ugly
> >> modes
From: Ville Syrjälä
Let's switch the pipe into interlaced mode and switch off
the TV encoder vertical filter if the pipe vdisplay
matches the TV YSIZE exactly.
While I didn't measure it I presume this might reduce
the power consumption a little bit, and the pixel rate
is halved as the pipe will
From: Ville Syrjälä
intel_tv_mode_to_mode() assumes the pipe will be in progressive
fetch mode, and thus when programming the pipe into interlaced
mode we have to halve the calculated dotclock to get the correct
field duration.
This becomes more important when we start to program the pipe
into i
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
The intention is to enable it on older generations after it has seen more
testing on gen9+.
VLV and CHV devices are still being sold
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:56 PM
>To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
>dri-de...@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 2
On Fri, Jan 25, 2019 at 01:54:47PM -0800, Matt Roper wrote:
> On Fri, Jan 25, 2019 at 08:38:46PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We're incorrectly masking off the R/V channel enable bit from
> > KEYMSK. Fix it up.
> >
> > Cc: Maarten Lankhorst
> > Cc: Matt Roper
> >
== Series Details ==
Series: series starting with [1/3] drm/irq: Don't check for DRIVER_HAVE_IRQ in
drm_irq_(un)install
URL : https://patchwork.freedesktop.org/series/55894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5500_full -> Patchwork_12066_full
==
On Tue, Jan 29, 2019 at 11:42:48AM +0100, Daniel Vetter wrote:
> This is only used by drm_irq_install(), which is an optional helper.
> For legacy pci devices this is required (due to interrupt sharing without
> msi/msi-x), and just making this the default exactly matches the behaviour
> of all exi
On Tue, Jan 29, 2019 at 04:33:15PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 25, 2019 at 01:54:47PM -0800, Matt Roper wrote:
> > On Fri, Jan 25, 2019 at 08:38:46PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We're incorrectly masking off the R/V channel enable bit from
> > >
On Tue, Jan 29, 2019 at 04:19:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's switch the pipe into interlaced mode and switch off
> the TV encoder vertical filter if the pipe vdisplay
> matches the TV YSIZE exactly.
>
> While I didn't measure it I presume this might reduce
> the
Hi,
On 29-01-19 15:02, Joonas Lahtinen wrote:
Quoting Hans de Goede (2019-01-25 10:36:48)
Hi Rodrigo and Maarten,
On 24-01-19 23:20, Rodrigo Vivi wrote:
On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
From: Hans de Goede
We really want to have fastboot enabled by default
Hi Uma,
On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 5:54 PM
> >To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> >dri-de...@lists.freed
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scen
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with prop
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like 601,
709, BT2020 etc. This helps to switch based on content type which is
to be displayed. The decision lies with compositors as to in which
scenarios, a particular
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, January 29, 2019 3:49 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v6 3/6] drm/i915/icl: Add icl pipe degamma and gamma support
>
>On Wed,
== Series Details ==
Series: series starting with [1/2] drm/i915/tv: Fix adjusted_mode dotclock for
interlaced modes
URL : https://patchwork.freedesktop.org/series/55909/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12070
===
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, January 29, 2019 3:50 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v6 4/6] drm/i915/icl: Enable ICL Pipe CSC block
>
>On Wed, Jan 16, 2019
On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appro
>-Original Message-
>From: Roper, Matthew D
>Sent: Tuesday, January 29, 2019 3:50 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v6 5/6] drm/i915/icl: Enable pipe output csc
>
>On Wed, Jan 16, 2019 at
Hi,
On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote:
> On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
> > >> +#define DP_COLORIMETRY_SCRGB 15
> > >> +#define DP_COLORIMETRY_DCI_P3 16
> > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17
>
> Sorry,
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 9:14 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-gfx@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-de...@l
== Series Details ==
Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter
URL : https://patchwork.freedesktop.org/series/55898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5500_full -> Patchwork_12067_full
On Wed, Jan 16, 2019 at 09:51:01PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 16, 2019 at 08:58:04PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 16, 2019 at 10:31:56AM -0800, Matt Roper wrote:
> > > On Fri, Jan 11, 2019 at 07:08:18PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
>-Original Message-
>From: Daniel Stone [mailto:dan...@fooishbar.org]
>Sent: Tuesday, January 29, 2019 9:24 PM
>To: Brian Starkey
>Cc: Shankar, Uma ; Syrjala, Ville
>; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; nd ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx]
On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, January 29, 2019 9:14 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-
Make sure the underlying VMA in the process address space is the
same as it was during vm_mmap to avoid applying WC to wrong VMA.
A more long-term solution would be to have vm_mmap_locked variant
in linux/mmap.h for when caller wants to hold mmap_sem for an
extended duration.
v2:
- Refactor the c
Add err goto label and use it when VMA can't be established or changes
underneath.
v2:
- Dropping Fixes: as it's indeed impossible to race an object to the
error address. (Chris)
Reported-by: Adam Zabrocki
Signed-off-by: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Adam Zabrocki
Quoting Joonas Lahtinen (2019-01-29 16:12:37)
> Add err goto label and use it when VMA can't be established or changes
> underneath.
>
> v2:
> - Dropping Fixes: as it's indeed impossible to race an object to the
> error address. (Chris)
>
> Reported-by: Adam Zabrocki
> Signed-off-by: Joonas La
Quoting Joonas Lahtinen (2019-01-29 16:12:36)
> Make sure the underlying VMA in the process address space is the
> same as it was during vm_mmap to avoid applying WC to wrong VMA.
>
> A more long-term solution would be to have vm_mmap_locked variant
> in linux/mmap.h for when caller wants to hold
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 9:34 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-gfx@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-de...@lists.freedesktop.org
>Subject: Re:
== Series Details ==
Series: series starting with [1/8] drm/i915: Rename execlists->queue_priority
to preempt_priority_hint (rev2)
URL : https://patchwork.freedesktop.org/series/55886/
State : failure
== Summary ==
Applying: drm/i915: Rename execlists->queue_priority to preempt_priority_hint
== Series Details ==
Series: drm/i915: Enable fastboot by default on VLV and CHV
URL : https://patchwork.freedesktop.org/series/55911/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12071
Summary
---
== Series Details ==
Series: Add Colorspace connector property interface (rev8)
URL : https://patchwork.freedesktop.org/series/47132/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e750c2ac7554 drm: Add colorspace connector property
c442445b3ffa drm/i915: Attach colorspace prope
On Tue, Jan 29, 2019 at 04:20:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 9:34 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-gfx@lists.freedesktop.org; Syrjala,
== Series Details ==
Series: drm/i915/gen9: Disable FBC on planes which have an unsupported config.
URL : https://patchwork.freedesktop.org/series/55900/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5500_full -> Patchwork_12068_full
===
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 10:09 PM
>To: Shankar, Uma
>Cc: Syrjala, Ville ; intel-gfx@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-de...@lists.freedesktop.org;
== Series Details ==
Series: Add Colorspace connector property interface (rev8)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12073
Summary
---
On Tue, Jan 29, 2019 at 04:49:19PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 29, 2019 at 04:33:15PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 25, 2019 at 01:54:47PM -0800, Matt Roper wrote:
> > > On Fri, Jan 25, 2019 at 08:38:46PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably su
1 - 100 of 207 matches
Mail list logo
