Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and keep track of inflight nodes so we can reap the
stale entries upon parking (thereby trimming our memory usage).
Signed-off-by: Chris Wilson
---
Move i915_gt_active_fini() out of struct_mutex for mock device t
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
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
On Fri, 2018-12-21 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I thought we could remove all the early latency==0 checks
> and rely on skl_wm_method{1,2}() checking for it. But
> skl_compute_plane_wm() applies a bunch of workarounds to bump
> up the latency before calling those
On Fri, 2018-12-21 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On glk+ the level 0 lines watermark actually matters. Do not ignore
> it.
> And while at it let's change things so that we always program a
> consistnet 0 to the register when the lines watermarks is ignored
> by th
On Fri, 2018-12-21 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The spec used to say "8bpp" which someone took to mean 8 bytes per
> pixel when in fact it was supposed to be 8 bits per pixel. The
> spec has been updated to make it more clear now. Fix the code
> to match.
>
> Si
== Series Details ==
Series: Add Colorspace connector property interface (rev7)
URL : https://patchwork.freedesktop.org/series/47132/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
997f79fd2b2f drm: Add colorspace connector property
7195c72c35da drm/i915: Attach colorspace prope
== Series Details ==
Series: Add Colorspace connector property interface (rev7)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5490 -> Patchwork_12056
Summary
---
Chris Wilson writes:
> During igt, we ask to reset the device if any requests are still
> outstanding at the end of a test, as this quickly kills off any
> erroneous hanging request streams that may escape a test. However, since
> it may take the device a few milliseconds to flush itself after th
The patch look ok to me.
On Fri, 2019-01-11 at 19:49 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
> which misprograms the hardware badly when encountering a suitably
> high resolution display. The programmed pipe timings a
Quoting Mika Kuoppala (2019-01-28 09:24:12)
> Chris Wilson writes:
>
> > During igt, we ask to reset the device if any requests are still
> > outstanding at the end of a test, as this quickly kills off any
> > erroneous hanging request streams that may escape a test. However, since
> > it may tak
On 28/01/2019 01:02, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a
Check we can reset the GPU before running the reset test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 21292bf3a..1fdbcc154 100644
--- a/tests/perf_pmu.c
+
Check we can reset the GPU before running the reset test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Different meaning of flags, it's not the ring id!
---
tests/perf_pmu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as t
Remove the struct_mutex requirement for looking up the vma for an
object.
v2: Highlight how the race for duplicate vma creation is resolved on
reacquiring the lock with a short comment.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracki
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h |
Currently we only allocate an object and vma if we are using a GGTT
virtual HWSP, and a plain struct page for a physical HWSP. For
convenience later on with global timelines, it will be useful to always
have the status page being tracked by a struct i915_vma. Make it so.
Signed-off-by: Chris Wilso
== Series Details ==
Series: Add Colorspace connector property interface (rev7)
URL : https://patchwork.freedesktop.org/series/47132/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5490_full -> Patchwork_12056_full
Summary
-
On 28/01/2019 01:02, 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
On Fri, Jan 25, 2019 at 11:16:08PM +0200, Souza, Jose wrote:
> On Fri, 2019-01-25 at 16:34 +0200, Imre Deak wrote:
> > We can't safely probe Type C ports, whether they are a legacy or a
> > USB/Thunderbolt DP Alternate Type C port. This would require
> > performing
> > the TypeC connect sequence -
On 28/01/2019 10:18, Chris Wilson wrote:
Check we can reset the GPU before running the reset test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Different meaning of flags, it's not the ring id!
---
tests/perf_pmu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --g
On 27/01/2019 13:06, Chris Wilson wrote:
Check that we are allowed to reset the GPU prior to execution.
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workaro
Quoting Tvrtko Ursulin (2019-01-28 10:56:24)
>
> On 28/01/2019 01:02, 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
Quoting Tvrtko Ursulin (2019-01-28 11:03:30)
>
> On 27/01/2019 13:06, Chris Wilson wrote:
> > Check that we are allowed to reset the GPU prior to execution.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/gem_workarounds.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion
Quoting Chris Wilson (2019-01-28 11:07:40)
> Quoting Tvrtko Ursulin (2019-01-28 11:03:30)
> >
> > On 27/01/2019 13:06, Chris Wilson wrote:
> > > Check that we are allowed to reset the GPU prior to execution.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > tests/i915/gem_workarounds.c |
Check that we are allowed to reset the GPU prior to execution.
v2: Push the require checking up into a subgroup
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_workarou
Quoting Tvrtko Ursulin (2019-01-28 11:00:43)
>
> On 28/01/2019 10:18, Chris Wilson wrote:
> > Check we can reset the GPU before running the reset test.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > Different meaning of flags, it's not the ring id!
> > ---
> > tests/pe
On Sat, 26 Jan 2019, Sam Ravnborg wrote:
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused i915 to fail to build.
>
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from drm_modeset_helper.h.
>
> In the files touched the lists of
We can't safely probe Type C ports, whether they are a legacy or a
USB/Thunderbolt DP Alternate Type C port. This would require performing
the TypeC connect sequence - as described by the specification - but
that may have unwanted side-effects. These side-effects include at least
- without complete
On 2019/01/25, Daniel Vetter wrote:
> On Fri, Jan 25, 2019 at 02:46:55PM +, Emil Velikov wrote:
> > On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
> > >
> > > This is only used by drm_irq_install(), which is an optional helper.
> > > And the right choice is to set it for all pci devices, a
On Fri, Jan 25, 2019 at 08:24:35PM -0500, Lyude Paul wrote:
> Turns out we are sending a lot more hotplug events then we need, and
> this is causing some pretty serious issues. Currently, we call
> intel_dp_mst_resume() in i915_drm_resume() well before we have any sort
> of hotplugging setup.
We c
On 28/01/2019 11:12, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-28 11:07:40)
Quoting Tvrtko Ursulin (2019-01-28 11:03:30)
On 27/01/2019 13:06, Chris Wilson wrote:
Check that we are allowed to reset the GPU prior to execution.
Signed-off-by: Chris Wilson
---
tests/i915/gem_workaro
On 28/01/2019 11:23, Chris Wilson wrote:
Check that we are allowed to reset the GPU prior to execution.
v2: Push the require checking up into a subgroup
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 29 ++---
1 file changed, 26 insertions(+), 3 dele
Quoting Tvrtko Ursulin (2019-01-28 13:44:47)
>
> On 28/01/2019 11:12, Chris Wilson wrote:
> Agreed on that, but worry who will notice it in review.
For the next week of struct_mutex removal (haha), CI will tell us.
-Chris
___
Intel-gfx mailing list
Inte
On Fri, Jan 25, 2019 at 10:17:04PM +0200, Imre Deak wrote:
> On Fri, Jan 25, 2019 at 08:19:31PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Just like the frame counter, the pixel counter also reads zero
> > all the time when the TV encoder is used. Fortunately the
> > scanline cou
On Mon, Jan 28, 2019 at 09:30:35AM +, Kahola, Mika wrote:
> The patch look ok to me.
>
> On Fri, 2019-01-11 at 19:49 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
> > which misprograms the hardware badly when enco
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on
VMA
URL : https://patchwork.freedesktop.org/series/55829/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Stop tracking MRU activity on VMA
Oka
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on
VMA
URL : https://patchwork.freedesktop.org/series/55829/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494 -> Patchwork_12057
=
On 28/01/2019 01:02, Chris Wilson wrote:
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 immediat
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
URL : https://patchwork.freedesktop.org/series/55733/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5494 -> Patchwork_12058
Summary
--
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
URL : https://patchwork.freedesktop.org/series/55733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494 -> Patchwork_12058
Summary
--
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum pe
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh alloca
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55850/
State : failure
== Summary ==
Applying: drm/i915: Introduce concept of per-timeline (context) HWSP
Applying: drm/i915: En
On Mon, 2019-01-28 at 13:42 +0200, Imre Deak wrote:
> We can't safely probe Type C ports, whether they are a legacy or a
> USB/Thunderbolt DP Alternate Type C port. This would require
> performing
> the TypeC connect sequence - as described by the specification - but
> that may have unwanted side-e
Hi Dave,
This pull includes the tag as described below and the GVT stuff, which
"
includes Coffeelake support for GVT,
making kvmgt as self load module to have better dependence with
vfio/mdev, with some const treatment and kernel type change.
"
Also please notice that we have a drm color managem
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh alloca
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum pe
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP
== Series Details ==
Series: icl: Misc PLL patches (rev3)
URL : https://patchwork.freedesktop.org/series/55378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5496 -> Patchwork_12060
Summary
---
**SUCCESS**
No regr
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55856/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d5418c9092a6 drm/i915: Introduce concept of per-timeline (c
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55856/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Introduce concept of p
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5497 -> Patchwork_12061
==
On Fri, Jan 25, 2019 at 05:28:40PM -0800, Matt Roper wrote:
> Use of the new DRM_COLOR_LUT_NON_DECREASING test was a bit over-zealous;
> it doesn't actually need to be applied to the degamma on "bdw-style"
> platforms. Likewise, we overlooked the fact that CHV should have that
> test applied to th
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on
VMA
URL : https://patchwork.freedesktop.org/series/55829/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494_full -> Patchwork_12057_full
===
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
URL : https://patchwork.freedesktop.org/series/55733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494_full -> Patchwork_12058_full
We have a bad habit of calling drm_fb_helper_hotplug_event() far more
then we actually need to. MST appears to be one of these cases, where we
call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
topology in intel_dp_mst_resume(). We don't actually need to do this at
all though s
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.
However, sending a hotplug event involves calling
drm_f
While trying to fix a problem with suspend/resume that I introduced in
the atomic VCPI helpers for MST, I also ran into some issues with i915
varying from "not that bad" to "oh wow that's very bad". Here are the
fixes for those issues.
This series was originally just one patch,
"drm/i915: Don't se
This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
1
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:52:56PM -0800, Eric Anholt wrote:
> >>> Daniel Vetter writes:
> >>>
> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote
== Series Details ==
Series: drm/i915: MST and wakeref leak fixes
URL : https://patchwork.freedesktop.org/series/55868/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
642ed0b4731b drm/i915: Block fbdev HPD processing during suspend
-:69: WARNING:BOOL_BITFIELD: Avoid using bool a
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:52:56PM -0800, Eric Anholt wrote:
> Daniel Vetter writes:
>
>> On Tue, Nov
On Wed, Jan 16, 2019 at 09:51:33PM +0530, Uma Shankar wrote:
> Fixed the glk degamma lut programming which currently
> was hard coding a linear lut all the time, making degamma
> block of glk basically a pass through.
>
> Currently degamma lut for glk is assigned as 0 in platform
> configuration.
== Series Details ==
Series: drm/i915: MST and wakeref leak fixes
URL : https://patchwork.freedesktop.org/series/55868/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498 -> Patchwork_12062
Summary
---
**SUCCESS**
Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active
Ironlake does support being able to saving and reloading context specific
registers between contexts, providing isolation of the basic GPU state
(as programmable by userspace). This allows userspace to assume that the
GPU retains their state from one batch to the next, minimising the
amount of stat
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimis
On Mon, Jan 28, 2019 at 3:26 PM Noralf Trønnes wrote:
>
>
>
> 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:52:56PM -080
Arrange macros definitions for ICL, CNL and MG phy programming registers
semantically in order by dword, lane and port; to make it consistent.
Aditya Swarup (2):
drm/i915: Make macro definitions consistent for ICL and CNL
drm/i915: Make MG phy macros semantically consistent
drivers/gpu/drm/
Macro definitions to be organized semantically based on dword, lane and
port(in this order).
Cc: Clint Taylor
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 6 +++---
drivers/gpu/drm/i915/icl_dsi.c | 8
drivers/gpu/drm/i915/intel
Macros to be organized semantically by dword, lane and
port(in this order).
Cc: Clint Taylor
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 50
drivers/gpu/drm/i915/intel_ddi.c | 44 ++-
On Wed, Jan 16, 2019 at 09:51:34PM +0530, Uma Shankar wrote:
> Add support for icl pipe degamma and gamma.
>
> v2: Removed a POSTING_READ and corrected the Bit
> Definition as per Maarten's comments.
>
> v3: Addressed Matt's review comments. Removed rmw patterns
> as suggested by Matt.
>
> v4: F
On Wed, Jan 16, 2019 at 09:51:35PM +0530, Uma Shankar wrote:
> Enable ICL pipe csc hardware. CSC block is enabled
> in CSC_MODE register instead of PLANE_COLOR_CTL.
>
> ToDO: Extend the ABI to accept 32 bit coefficient values
> instead of 16bit for future platforms.
>
> v2: Addressed Maarten's re
On Wed, Jan 16, 2019 at 09:51:36PM +0530, Uma Shankar wrote:
> GEN11+ onwards an output csc hardware block has been added.
> This is after the pipe gamma block and is in addition to the
> legacy pipe CSC block. Primary use case for this block is to
> convert RGB to YUV in case sink supports YUV.
>
== Series Details ==
Series: Make macro definitions consistent in intel_reg.h
URL : https://patchwork.freedesktop.org/series/55875/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1eaa92c3b871 drm/i915: Make macro definitions consistent for ICL and CNL
504ef6aa90ba drm/i915: Make
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/55874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498 -> Patchwork_12063
===
== Series Details ==
Series: Make macro definitions consistent in intel_reg.h
URL : https://patchwork.freedesktop.org/series/55875/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498 -> Patchwork_12064
Summary
---
**
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:52:56PM -0800, Eric Anholt wrote:
>> Daniel Vetter
== Series Details ==
Series: icl: Misc PLL patches (rev3)
URL : https://patchwork.freedesktop.org/series/55378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5496_full -> Patchwork_12060_full
Summary
---
**SUCCESS**
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 required for most client API
> level flow visualisation.
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5497_full -> Patchwork_12061_full
== Series Details ==
Series: drm/i915: MST and wakeref leak fixes
URL : https://patchwork.freedesktop.org/series/55868/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498_full -> Patchwork_12062_full
Summary
---
**WA
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/55874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498_full -> Patchwork_12063_full
=
== Series Details ==
Series: Make macro definitions consistent in intel_reg.h
URL : https://patchwork.freedesktop.org/series/55875/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498_full -> Patchwork_12064_full
Summary
---
95 matches
Mail list logo
