Hi,
On 11.2.2019 11.49, Tvrtko Ursulin wrote:
On 08/02/2019 13:58, Eero Tamminen wrote:
On 8.2.2019 14.03, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Two new output modes are added: listing of text data to standard out (-l
on the command line), and dumping of JSON formatted records (-J),
al
On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> Hi all,
>
> Here's the typed component topic branch.
>
> drm-intel maintainers: Please pull, I need this for the mei hdcp work from
> Ram.
>
> drm-misc maintainers: Please pull, there's a drm doc patch follow-up
> that I want to s
Hi all,
Unfortunately, freedesktop.org's job of sending mail to a huge number
of people whilst pretending to be other people, has just got even
harder than it was.
fd.o can no longer (at least for the moment) send mail with the From
addresses of DMARC/DKIM/SPF-protected sender domains. When we try
Only wait a maximum of 2 more seconds for the hang children to complete,
to catch deadlocks in a timely fashion.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_mmap_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915
We cannot nest i915_reset_trylock() as the inner may wait for the
I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
waiting for our outermost lock. As we take the reset srcu around the
fence update, we have to defer taking it in i915_gem_fault() until after
we acquire the pin on the
== Series Details ==
Series: drm/i915: Recursive i915_reset_trylock() verboten
URL : https://patchwork.freedesktop.org/series/56529/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Recursive i915_reset_trylock() verboten
-O:drivers/gpu/drm/i91
Chris Wilson writes:
> Only wait a maximum of 2 more seconds for the hang children to complete,
> to catch deadlocks in a timely fashion.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> tests/i915/gem_mmap_gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Quoting Mika Kuoppala (2019-02-12 10:56:13)
> Chris Wilson writes:
>
> > Only wait a maximum of 2 more seconds for the hang children to complete,
> > to catch deadlocks in a timely fashion.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > tests/i915/gem_mmap_gtt.c | 2 +-
>
Chris Wilson writes:
> We cannot nest i915_reset_trylock() as the inner may wait for the
> I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
> waiting for our outermost lock. As we take the reset srcu around the
> fence update, we have to defer taking it in i915_gem_fault() until
== Series Details ==
Series: drm/i915: Recursive i915_reset_trylock() verboten
URL : https://patchwork.freedesktop.org/series/56529/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5591 -> Patchwork_12200
Summary
---
*
On 06/02/2019 13:03, Chris Wilson wrote:
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
v2: Replace global barrier for swapping over the ppgtt and tlbs with a
Quoting Mika Kuoppala (2019-02-12 11:12:05)
> Chris Wilson writes:
>
> > We cannot nest i915_reset_trylock() as the inner may wait for the
> > I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
> > waiting for our outermost lock. As we take the reset srcu around the
> > fence updat
Use lockdep to warn before we wait indefinitely in case we may be
waiting indefinitely.
Suggested-by: Mika Kuoppala
References: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i91
>-Original Message-
>From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
>Sent: Monday, February 11, 2019 11:16 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org
>Subject: ✓ Fi.CI.IGT: success for Add support for Gen 11 pipe color features
>(rev9)
>
>== Series Details ==
>
== Series Details ==
Series: drm/i915: Detect potential i915_reset_trylock() lockups
URL : https://patchwork.freedesktop.org/series/56530/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5591 -> Patchwork_12201
Summary
--
Hi Daniel,
Thank you for the patch.
On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote:
> From: Daniel Vetter
>
> Now that component has docs it's worth spending a few words and
> hyperlinks on recommended best practices in drm.
>
> Cc: Russell King - ARM Linux admin
> Signed-off-by
Use lockdep to warn before we wait indefinitely in case we may be
waiting indefinitely.
Suggested-by: Mika Kuoppala
References: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i91
On Tue, Feb 12, 2019 at 02:44:03PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Sat, Feb 09, 2019 at 12:42:30PM +0530, Ramalingam C wrote:
> > From: Daniel Vetter
> >
> > Now that component has docs it's worth spending a few words and
> > hyperlinks on recomme
Use lockdep to warn before we wait indefinitely in case we may be
waiting indefinitely.
Suggested-by: Mika Kuoppala
References: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i91
== Series Details ==
Series: drm/i915: Recursive i915_reset_trylock() verboten
URL : https://patchwork.freedesktop.org/series/56529/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5591_full -> Patchwork_12200_full
Summary
--
Quoting Patchwork (2019-02-12 13:06:29)
> == Series Details ==
>
> Series: series starting with [2/2] drm/i915: Detect potential
> i915_reset_trylock() lockups (rev2)
> URL : https://patchwork.freedesktop.org/series/56533/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915: Detect pot
We cannot nest i915_reset_trylock() as the inner may wait for the
I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
waiting for our outermost lock. As we take the reset srcu around the
fence update, we have to defer taking it in i915_gem_fault() until after
we acquire the pin on the
Use lockdep to warn before we wait indefinitely in case we may be
waiting indefinitely.
Suggested-by: Mika Kuoppala
References: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i91
Quoting Tvrtko Ursulin (2019-02-11 16:56:03)
>
> On 11/02/2019 12:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-11 12:40:07)
> >>
> >> On 06/02/2019 13:03, Chris Wilson wrote:
> >>> To determine whether an engine has 'stuck', we simply check whether or
> >>> not is still on the same
On 06/02/2019 13:03, Chris Wilson wrote:
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be ap
Quoting Tvrtko Ursulin (2019-02-11 18:51:09)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > In the next patch, we are introducing a broad virtual engine to encompass
> > multiple physical engines, losing the 1:1 nature of BIT(engine->id). To
> > reflect the broader set of engines implied by the
Quoting Tvrtko Ursulin (2019-02-11 19:00:59)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > An idea for extending uABI inspired by Vulkan's extension chains.
> > Instead of expanding the data struct for each ioctl every time we need
> > to add a new feature, define an extension chain instead. As
== Series Details ==
Series: series starting with [1/2] drm/i915: Recursive i915_reset_trylock()
verboten
URL : https://patchwork.freedesktop.org/series/56535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5592 -> Patchwork_12203
==
Chris Wilson writes:
> Use lockdep to warn before we wait indefinitely in case we may be
> waiting indefinitely.
>
> Suggested-by: Mika Kuoppala
> References: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
> registers across reset")
> Signed-off-by: Chris Wilson
> Cc: Mika K
== Series Details ==
Series: series starting with [1/2] drm/i915: Recursive i915_reset_trylock()
verboten
URL : https://patchwork.freedesktop.org/series/56535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5592_full -> Patchwork_12203_full
On Tue, Feb 12, 2019 at 12:37:40PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> >Sent: Monday, February 11, 2019 11:16 PM
> >To: Shankar, Uma
> >Cc: intel-gfx@lists.freedesktop.org
> >Subject: ✓ Fi.CI.IGT: success for
On Fri, Feb 08, 2019 at 11:54: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
On Fri, Feb 08, 2019 at 11:54:55PM +0530, Uma Shankar wrote:
> This adds colorspace information to HDMI AVI infoframe.
> A helper function is added to program the same.
>
> v2: Moved this to drm core instead of i915 driver.
>
> v3: Exported the helper function.
>
> v4: Added separate HDMI specif
== Series Details ==
Series: drm/i915/query: Split out query item checks (rev3)
URL : https://patchwork.freedesktop.org/series/54917/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5589_full -> Patchwork_12197_full
Summary
-
On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> Hi all,
>
> Here's the typed component topic branch.
>
> drm-intel maintainers: Please pull, I need this for the mei hdcp work from
> Ram.
I'm about to handle dinq to Joonas since I did latest pull-request for 5.1
last week.
Also
== Series Details ==
Series: drm/i915: Show the GEM trace if reset times out
URL : https://patchwork.freedesktop.org/series/56512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5590_full -> Patchwork_12199_full
Summary
Quoting Patchwork (2019-02-12 12:39:58)
> == Series Details ==
>
> Series: drm/i915: Detect potential i915_reset_trylock() lockups
> URL : https://patchwork.freedesktop.org/series/56530/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5591 -> Patchwork_12201
>
== Series Details ==
Series: series starting with [2/2] drm/i915: Detect potential
i915_reset_trylock() lockups (rev2)
URL : https://patchwork.freedesktop.org/series/56533/
State : failure
== Summary ==
Applying: drm/i915: Detect potential i915_reset_trylock() lockups
Applying: drm/i915: Dete
We cannot nest i915_reset_trylock() as the inner may wait for the
I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
waiting for our outermost lock. As we take the reset srcu around the
fence update, we have to defer taking it in i915_gem_fault() until after
we acquire the pin on the
Quoting Tvrtko Ursulin (2019-02-12 11:18:16)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > In preparation to making the ppGTT binding for a context explicit (to
> > facilitate reusing the same ppGTT between different contexts), allow the
> > user to create and destroy named ppGTT.
> >
> > v2:
Quoting Tvrtko Ursulin (2019-02-11 19:11:08)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > @@ -1361,6 +1362,7 @@ __execlists_context_pin(struct intel_engine_cs
> > *engine,
> >
> > ce->state->obj->pin_global++;
> > i915_gem_context_get(ctx);
> > + list_add(&ce->active_link,
Quoting Tvrtko Ursulin (2019-02-11 18:18:36)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > As we no longer have a precise indication of requests queued to an
> > engine, make no presumptions and just sample the ring registers to see
> > if the engine is busy.
> >
> > v2: Report busy while the
Quoting Tvrtko Ursulin (2019-02-11 17:02:19)
>
> On 11/02/2019 12:40, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-11 11:43:41)
> >>
> >> On 06/02/2019 13:03, Chris Wilson wrote:
> >>> As kmem_caches share the same properties (size, allocation/free behaviour)
> >>> for all potential dev
Use lockdep to warn before we wait indefinitely in case we may be
waiting indefinitely.
Suggested-by: Mika Kuoppala
References: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i91
The timer is initialized with TIMER_IRQSAFE flag. It does look like the
timer callback requires this flag at all. Its sole purpose is to ensure
synchronisation in the workqueue code.
Remove TIMER_IRQSAFE flag because it is not required.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc:
== Series Details ==
Series: drm/i915: Detect potential i915_reset_trylock() lockups
URL : https://patchwork.freedesktop.org/series/56530/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b466625617f1 drm/i915: Detect potential i915_reset_trylock() lockups
-:10: WARNING:COMMIT_LOG
== Series Details ==
Series: series starting with [1/2] drm/i915: Recursive i915_reset_trylock()
verboten
URL : https://patchwork.freedesktop.org/series/56535/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
47ca4b30856e drm/i915: Recursive i915_reset_trylock() verboten
f35c801a
== Series Details ==
Series: series starting with [1/2] drm/i915: Recursive i915_reset_trylock()
verboten
URL : https://patchwork.freedesktop.org/series/56535/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Recursive i915_reset_trylock() ver
Quoting Tvrtko Ursulin (2019-02-11 18:44:50)
>
> On 06/02/2019 13:03, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index a674c78ca1f8..8792ad12373d 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/driver
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 12, 2019 10:32 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v15 4/4]
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of
== Series Details ==
Series: drm/i915: Detect potential i915_reset_trylock() lockups (rev2)
URL : https://patchwork.freedesktop.org/series/56530/
State : failure
== Summary ==
Applying: drm/i915: Detect potential i915_reset_trylock() lockups
Using index info to reconstruct a base tree...
M
== Series Details ==
Series: drm/i915/fence: Do not use TIMER_IRQSAFE
URL : https://patchwork.freedesktop.org/series/56558/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5594 -> Patchwork_12204
Summary
---
**FAILURE*
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915/
As we have moved to rcu/srcu to serialise the resets, individual resets
are subject to small variations in system grace periods. Allow for this
by only expecting the median reset time to be within our target, thereby
excluding noisy outliers from perturbing our results (but keep the
maximum capped
Older platforms need to clobber the display around a reset (incl. a
modeset to off, and a modeset back on), which can be much slower than
the reset itself. Give these platforms (gen2-4) some leniency and allow
them a higher limit before declaring them a failure.
Signed-off-by: Chris Wilson
---
t
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 12, 2019 10:35 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject:
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 12, 2019 9:56 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Add support for Gen 11 pipe
>color
>features (rev9)
>
>On T
As we track when we put the GT device to sleep upon idling, we can use
that callback to sample the current rc6 counters and record the
timestamp for estimating samples after that point while asleep.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pmu.c | 83
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915/
On 29/01/19 10:01, Chris Wilson wrote:
Quoting Antonio Argenziano (2019-01-29 17:55:45)
On 29/01/19 01:55, Chris Wilson wrote:
Present the latency results in nanoseconds not RCS cycles.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 38 +++--
Quoting Chris Wilson (2019-02-12 22:39:46)
> As we track when we put the GT device to sleep upon idling, we can use
> that callback to sample the current rc6 counters and record the
> timestamp for estimating samples after that point while asleep.
Bah, the perf_pmu/rc6 test bypasses the GPU and po
Quoting Antonio Argenziano (2019-02-12 23:06:06)
>
>
> On 29/01/19 10:01, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2019-01-29 17:55:45)
> >>
> >>
> >> On 29/01/19 01:55, Chris Wilson wrote:
> >>> Present the latency results in nanoseconds not RCS cycles.
> >>>
> >>> Signed-off-by: Chri
== Series Details ==
Series: drm/i915/pmu: Use GT parked for estimating RC6 while asleep
URL : https://patchwork.freedesktop.org/series/56583/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5595 -> Patchwork_12206
Summary
--
On Mon, Jan 28, 2019 at 02:00:11PM -0800, Aditya Swarup wrote:
> 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
I think you can change the commit message to sa
On Mon, Jan 28, 2019 at 02:00:12PM -0800, Aditya Swarup wrote:
> 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
Also please add Fixes tag with SHA of the original patch that
ad
== Series Details ==
Series: drm/i915/pmu: Use GT parked for estimating RC6 while asleep
URL : https://patchwork.freedesktop.org/series/56583/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5595_full -> Patchwork_12206_full
From: Michel Thierry
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.
To start the discussion, include just a total en
From: Michel Thierry
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to su
From: Michel Thierry
XXX: What to do when the watchdog irq fired twice but our hangcheck
logic thinks the engine is not hung? For example, what if the
active-head moved since the irq handler?
One option is to just ignore the watchdog, if the engine is really hung,
then the driver will detect the
This is a rebased on the original patch series from Michel Thierry
that can be found here:
https://patchwork.freedesktop.org/series/21868
Note that this series is only limited to the GPU Watchdog timeout
for execlists as it leaves out support
for GuC based submission for a later time.
PATCH v2 o
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for vide
From: Michel Thierry
Save the watchdog threshold (in us) as part of the engine state.
v2: Only do it for gen8+ (and prevent a missing-case warn).
v3: use ctx->__engine.
v4: Rebase.
v5: Rebase.
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
From: Michel Thierry
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_
== Series Details ==
Series: Gen8+ GPU Watchdog Reset Support
URL : https://patchwork.freedesktop.org/series/56587/
State : failure
== Summary ==
Applying: drm/i915: Add engine reset count in get-reset-stats ioctl
Applying: drm/i915: Watchdog timeout: IRQ handler for gen8+
Using index info to
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 adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. Thi
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colo
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
== Series Details ==
Series: Add Colorspace connector property interface (rev15)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5596 -> Patchwork_12208
Summary
---
81 matches
Mail list logo
