On ke, 2017-04-05 at 22:07 +0100, Chris Wilson wrote:
> When discussing a new WC mmap, we based the interface upon the
> assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef
> ("drm/i915: Wait for writes through the GTT to land before reading
> back") and ed4596ea992d ("drm/i915/
On ke, 2017-04-05 at 16:30 +0100, Chris Wilson wrote:
> When we update the global seqno (on the engine timeline), we modify HW
> state (both registers and mapped pages). As we do this, we should be
> sure that the HW is idle and we are not causing a conflict. The caller
> is supposed to wait_for_id
On Wed, Apr 05, 2017 at 03:59:52PM -0400, Sean Paul wrote:
> Along with a recipe for creating a topic branch and sending a pull
> request from it.
>
> Signed-off-by: Sean Paul
Applied, thanks.
-Daniel
> ---
>
> Changes in v2:
> - Address danvet's comments
> - added paragraph about select
On to, 2017-04-06 at 18:00 +0100, Chris Wilson wrote:
> When we retire the last request on the ring, before we ever access that
> ring again we know it will be completely idle and so we can advance the
> ring->head fully to the end (i.e. ring->tail) and not just to the start
> of the breadcrumb. Th
On Thu, Apr 06, 2017 at 07:34:41PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm: Take mode_config.mutex in setcrtc ioctl (rev2)
> URL : https://patchwork.freedesktop.org/series/22605/
> State : failure
>
> == Summary ==
>
> Series 22605v2 drm: Take mode_config.mutex in setcrt
On Thu, 2017-03-30 at 20:43 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/GuC/GLK: Load GuC on GLK
> URL : https://patchwork.freedesktop.org/series/22237/
> State : success
Pushed to dinq. Thanks for the patches and reviews!
Ander
>
> == Summa
On Fri, Apr 07, 2017 at 10:16:52AM +0300, Joonas Lahtinen wrote:
> On ke, 2017-04-05 at 22:07 +0100, Chris Wilson wrote:
> > When discussing a new WC mmap, we based the interface upon the
> > assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef
> > ("drm/i915: Wait for writes thr
On 06/04/2017 16:00, Oscar Mateo wrote:
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko, Chris)
- Make sure the mock engine name is null-terminated (Tvrtko, Chris)
v3: Because I'm stupid (Chr
On 06/04/2017 16:00, Oscar Mateo wrote:
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
Cc: Tvrtko Ursulin
Cc: Paulo
Looks ok to me.
On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> Also in a way that reuse bdw+ for all next platforms.
>
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On 06/04/2017 18:40, Tvrtko Ursulin wrote:
On 06/04/2017 10:30, Chris Wilson wrote:
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting
The function igt_debugfs_open() would not close the debugfs dir before
returning. Tests that do a lot of pipe CRC comparaions, such as
kms_cursor_crc, would eventually fail.
(kms_cursor_crc:3853) igt-debugfs-CRITICAL: Test assertion failure function
igt_pipe_crc_do_start, file igt_debugfs.c:387:
Hi,
Still need this one from Min for correct execlist csb initial
read ptr fix, which could possibly cause guest hang.
Thanks.
---
The following changes since commit aa4ce4493c88dc324911152d1ccd25469366dba3:
drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state
(2017-04-01
On 06/04/2017 09:55, Chris Wilson wrote:
On Thu, Apr 06, 2017 at 09:18:36AM +0100, Tvrtko Ursulin wrote:
[snip]
+ j++;
+ }
+
+ bb_i = j++;
+ w->duration.cur = w->duration.max;
+ w->bb_sz = get_bb_sz(&w->duration);
On Fri, Apr 07, 2017 at 11:34:34AM +0300, Ander Conselvan de Oliveira wrote:
> The function igt_debugfs_open() would not close the debugfs dir before
> returning. Tests that do a lot of pipe CRC comparaions, such as
> kms_cursor_crc, would eventually fail.
>
> (kms_cursor_crc:3853) igt-debugfs-CR
Only call synchronize_rcu_expedited after unlocking struct_mutex to
avoid deadlock because the workqueues depend on struct_mutex.
From original patch by Andrea:
synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
w
On Fri, Apr 07, 2017 at 09:23:26AM +0100, Tvrtko Ursulin wrote:
>
> On 06/04/2017 18:40, Tvrtko Ursulin wrote:
> >On 06/04/2017 10:30, Chris Wilson wrote:
> >>If we attempt to wake up a waiter, who is currently checking the seqno
> >>it will be in the TASK_INTERRUPTIBLE state and ttwu will report
On pe, 2017-04-07 at 01:23 +0200, Andrea Arcangeli wrote:
> synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
> hang until its own workqueues are run. The i915 gem workqueues will
> wait on the struct_mutex to be released. So we cannot wait for a
> quiescent state using those rcu p
On Fri, Apr 07, 2017 at 10:25:13AM +0300, Joonas Lahtinen wrote:
> On to, 2017-04-06 at 18:00 +0100, Chris Wilson wrote:
> > When we retire the last request on the ring, before we ever access that
> > ring again we know it will be completely idle and so we can advance the
> > ring->head fully to th
== Series Details ==
Series: drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
URL : https://patchwork.freedesktop.org/series/22646/
State : success
== Summary ==
Series 22646v1 drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
https://patchwork.freedesktop.org/
On ke, 2017-03-29 at 14:58 +0100, Chris Wilson wrote:
> We want to refer to the index of the engine consistently throughout the
> userspace ABI. We already have such an index through the execbuffer
> engine specifier, that needs to be able to refer to each engine
> specifically.
>
> Signed-off-by:
On Fri, Apr 07, 2017 at 09:18:17AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
> URL : https://patchwork.freedesktop.org/series/22646/
> State : success
>
> == Summary ==
>
> Series 22646v1 drm/i915: Don't call sy
On Thu, Apr 06, 2017 at 08:00:12AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> In such a way that vcs and vcs2 are just two different instances (0 and 1)
> of the same engine class (VIDEO_DECODE_CLASS).
>
> v2: Align the instance types (Tvrtko)
>
> Cc: Paulo Zanoni
> Cc: Rodri
On Fri, Apr 07, 2017 at 09:53:05AM +0100, Tvrtko Ursulin wrote:
>
> On 06/04/2017 09:55, Chris Wilson wrote:
> >On Thu, Apr 06, 2017 at 09:18:36AM +0100, Tvrtko Ursulin wrote:
>
> [snip]
[snip]
> + if (swap_vcs && engine == VCS1)
> + engine = VCS2;
> +
On Fri, Apr 07, 2017 at 11:45:32AM +0200, Michal Wajdeczko wrote:
> On Thu, Apr 06, 2017 at 08:00:12AM -0700, Oscar Mateo wrote:
> > From: Daniele Ceraolo Spurio
> >
> > In such a way that vcs and vcs2 are just two different instances (0 and 1)
> > of the same engine class (VIDEO_DECODE_CLASS).
>
On Fri, Apr 07, 2017 at 01:23:47AM +0200, Andrea Arcangeli wrote:
> Insist to run llist_del_all() until the free_list is found empty, this
> may avoid having to schedule more workqueues.
The work will already be scheduled (everytime we add the first element,
the work is scheduled, and the schedule
On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> Waiting a RCU grace period only guarantees the work gets queued, but
> until after the queued workqueue returns, there's no guarantee the
> memory was actually freed. So flush the work to provide better
> guarantees to the reclaim
As we may have very many objects to free, check to see if the task needs
to be rescheduled whilst freeing them.
Suggested-by: Andrea Arcangeli
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/d
As we call into the shrinker during freeze, we may have freed more
object since we idled during i915_gem_suspend. Make sure we flush the
i915_gem_free_objects worker prior to saving the unwanted pages into the
hibernation image.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/dr
The shrinker is prepared to be called unlock (and with struct_mutex held
for DIRECT_RECLAIM) so we can skip acquiring the struct_mutex prior to
calling the shrinking during freeze. This improves our ability to shrink
as we can be more aggressive when we know the caller isn't holding
struct_mutex.
Before freeing the next batch of objects from the worker, check if the
worker's timeslice has expired and if so, defer the next batch to the
next invocation of the worker.
Suggested-by: Andrea Arcangeli
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++
On Thu, Apr 06, 2017 at 08:00:14AM -0700, Oscar Mateo wrote:
> Not really needed, but makes the next change a little bit more compact.
>
> v2:
> - Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko,
> Chris)
> - Make sure the mock engine name is null-terminated (Tvrtko, Chri
On Fri, Apr 07, 2017 at 01:23:45AM +0200, Andrea Arcangeli wrote:
> Just in case the llist model changes and NULL isn't valid
> initialization.
>
> Signed-off-by: Andrea Arcangeli
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
== Series Details ==
Series: series starting with [1/4] drm/i915: The shrinker already acquires
struct_mutex, so call it unlocked
URL : https://patchwork.freedesktop.org/series/22650/
State : success
== Summary ==
Series 22650v1 Series without cover letter
https://patchwork.freedesktop.org/ap
By using the same structure for both interruptible and
uninterruptible locking in shrinker code, combined with the
information that mm.interruptible is only being written to, the
code can be greatly simplified.
Also removing the i915_gem_ prefix from the locking functions so
that nobody in their w
Only call synchronize_rcu_expedited after unlocking struct_mutex to
avoid deadlock because the workqueues depend on struct_mutex.
From original patch by Andrea:
synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
w
On Thu, Apr 06, 2017 at 08:00:15AM -0700, Oscar Mateo wrote:
> There are some properties that logically belong to the engine class, and some
> that belong to the engine instance. Make it explicit.
>
> v2: Commit message (Tvrtko)
>
> v3:
> - Rebased
> - Exec/uabi id should be per instance (Chr
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> The shrinker is prepared to be called unlock (and with struct_mutex held
> for DIRECT_RECLAIM) so we can skip acquiring the struct_mutex prior to
> calling the shrinking during freeze. This improves our ability to shrink
> as we can be more ag
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> As we call into the shrinker during freeze, we may have freed more
> object since we idled during i915_gem_suspend. Make sure we flush the
> i915_gem_free_objects worker prior to saving the unwanted pages into the
> hibernation image.
>
> Sig
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> Before freeing the next batch of objects from the worker, check if the
> worker's timeslice has expired and if so, defer the next batch to the
> next invocation of the worker.
>
> Suggested-by: Andrea Arcangeli
> Signed-off-by: Chris Wilson
On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> As we may have very many objects to free, check to see if the task needs
> to be rescheduled whilst freeing them.
>
> Suggested-by: Andrea Arcangeli
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regard
== Series Details ==
Series: series starting with [1/2] drm/i915: Don't call
synchronize_rcu_expedited under struct_mutex
URL : https://patchwork.freedesktop.org/series/22652/
State : success
== Summary ==
Series 22652v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
On Fri, Apr 07, 2017 at 02:22:00PM +0300, Joonas Lahtinen wrote:
> On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> > As we call into the shrinker during freeze, we may have freed more
> > object since we idled during i915_gem_suspend. Make sure we flush the
> > i915_gem_free_objects worker
On Fri, Apr 07, 2017 at 01:49:35PM +0300, Joonas Lahtinen wrote:
> By using the same structure for both interruptible and
> uninterruptible locking in shrinker code, combined with the
> information that mm.interruptible is only being written to, the
> code can be greatly simplified.
>
> Also remov
Thanks for the review, pushing series.
On pe, 2017-04-07 at 11:25 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Don't call
> synchronize_rcu_expedited under struct_mutex
> URL : https://patchwork.freedesktop.org/series/22652/
> State : success
On Fri, Apr 07, 2017 at 02:23:58PM +0300, Joonas Lahtinen wrote:
> On pe, 2017-04-07 at 11:25 +0100, Chris Wilson wrote:
> > As we may have very many objects to free, check to see if the task needs
> > to be rescheduled whilst freeing them.
> >
> > Suggested-by: Andrea Arcangeli
> > Signed-off-by
On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > Waiting a RCU grace period only guarantees the work gets queued, but
> > until after the queued workqueue returns, there's no guarantee the
> > memory was actually f
On Fri, Apr 07, 2017 at 10:58:38AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:47AM +0200, Andrea Arcangeli wrote:
> > Insist to run llist_del_all() until the free_list is found empty, this
> > may avoid having to schedule more workqueues.
>
> The work will already be scheduled (eve
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. igt was blindly asserting it
supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_fli
On Thu, Apr 06, 2017 at 05:54:26PM -0700, Rodrigo Vivi wrote:
> Current VBT available for pre-production machines
> tells that we need to use alternate pin. But if we use it
> we end up needing to define a different table.
>
> However if we respect the spec, ignore the VBT for now
> we get a more
On Fri, 2017-04-07 at 16:19 +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 05:54:26PM -0700, Rodrigo Vivi wrote:
> > Current VBT available for pre-production machines
> > tells that we need to use alternate pin. But if we use it
> > we end up needing to define a different table.
> >
> > How
On Fri, Apr 07, 2017 at 02:15:26PM +0100, Daniel Stone wrote:
> DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
> whatever version of libdrm is present. igt was blindly asserting it
> supported whatever version that may be, even if it actually didn't.
>
> With libdrm 2.4.78, s
Hello Joonas,
On Fri, Apr 07, 2017 at 01:49:34PM +0300, Joonas Lahtinen wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 2978acd..129ed30 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_ge
In some cases we may want to spend more time in atomic wait than
hardcoded 2us. Let's add additional hint parameter to allow extending
internal atomic timeout to 10us before switching into heavy wait.
Signed-off-by: Michal Wajdeczko
Suggested-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Joonas Lah
There is no need to specify timeout as unsigned long since this parameter
will be consumed by usecs_to_jiffies() which expects unsigned int only.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_uncor
Waiting for the response status in scratch register can be done
using our generic function that waits for the expected register
state. Since completion of the GuC commands can take longer than
2us mark that wait as bit slower to extend atomic wait to 10us.
Signed-off-by: Michal Wajdeczko
Suggeste
On Thu, Apr 06, 2017 at 12:14:59PM -0700, Rodrigo Vivi wrote:
> RAWCLK_FREQ register has changed for platforms with CNP+.
>
> [29:26] This field provides the denominator for the fractional
> part of the microsecond counter divider. The numerator
> is fixed at 1. Program this field to
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix type of timeout_ms parameter
in intel_wait_for_register_fw()
URL : https://patchwork.freedesktop.org/series/22669/
State : warning
== Summary ==
Series 22669v1 Series without cover letter
https://patchwork.freedesktop.org/a
On 07/04/2017 14:32, Michal Wajdeczko wrote:
There is no need to specify timeout as unsigned long since this parameter
will be consumed by usecs_to_jiffies() which expects unsigned int only.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_dr
On 07/04/2017 14:32, Michal Wajdeczko wrote:
> In some cases we may want to spend more time in atomic wait than
> hardcoded 2us. Let's add additional hint parameter to allow extending
> internal atomic timeout to 10us before switching into heavy wait.
>
> Signed-off-by: Michal Wajdeczko
> Sugges
On Fri, Apr 07, 2017 at 02:58:17PM +0100, Tvrtko Ursulin wrote:
>
> On 07/04/2017 14:32, Michal Wajdeczko wrote:
> > In some cases we may want to spend more time in atomic wait than
> > hardcoded 2us. Let's add additional hint parameter to allow extending
> > internal atomic timeout to 10us before
On Thu, Apr 06, 2017 at 12:15:00PM -0700, Rodrigo Vivi wrote:
> Backlight support on Cannonpoint is a lot
> likely Broxton, but with only one controller (0).
This being the PCH backlight obviously. I guess we still don't have any
use for the CPU backlight?
Oh, since the utility pin is on the CPU
On Fri, Apr 07, 2017 at 01:32:11PM +, Michal Wajdeczko wrote:
> In some cases we may want to spend more time in atomic wait than
> hardcoded 2us. Let's add additional hint parameter to allow extending
> internal atomic timeout to 10us before switching into heavy wait.
Examples? I know the 2us
On Fri, Apr 07, 2017 at 03:32:30PM +0200, Andrea Arcangeli wrote:
> Hello Joonas,
> I kind I prefer my patch, just cleaned up with the
> synchronize_rcu_expedited under if (unlock) { mutex_unlock;
> synchronize_rcu... }.
Here a cleaned up version below using "unlock" instead of checking the
mutex
On Fri, Apr 07, 2017 at 04:10:29PM +0200, Michal Wajdeczko wrote:
> On Fri, Apr 07, 2017 at 02:58:17PM +0100, Tvrtko Ursulin wrote:
> >
> > On 07/04/2017 14:32, Michal Wajdeczko wrote:
> > > In some cases we may want to spend more time in atomic wait than
> > > hardcoded 2us. Let's add additional
On Fri, Apr 07, 2017 at 01:32:12PM +, Michal Wajdeczko wrote:
> Waiting for the response status in scratch register can be done
> using our generic function that waits for the expected register
> state. Since completion of the GuC commands can take longer than
> 2us mark that wait as bit slower
On Thu, Apr 06, 2017 at 12:15:02PM -0700, Rodrigo Vivi wrote:
> As for BXT, PP_DIVISOR was removed from CNP PCH and power
> cycle delay has been moved to PP_CONTROL.
>
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 10 +-
> 1 file changed, 5 in
On Fri, Apr 07, 2017 at 02:52:25PM +0100, Tvrtko Ursulin wrote:
>
> On 07/04/2017 14:32, Michal Wajdeczko wrote:
> >There is no need to specify timeout as unsigned long since this parameter
> >will be consumed by usecs_to_jiffies() which expects unsigned int only.
> >
> >Signed-off-by: Michal Wajd
On 07/04/2017 15:10, Michal Wajdeczko wrote:
On Fri, Apr 07, 2017 at 02:58:17PM +0100, Tvrtko Ursulin wrote:
On 07/04/2017 14:32, Michal Wajdeczko wrote:
In some cases we may want to spend more time in atomic wait than
hardcoded 2us. Let's add additional hint parameter to allow extending
inte
On Fri, Apr 07, 2017 at 03:06:00PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > > Waiting a RCU grace period only guarantees the work gets queued, but
> > > until after the qu
In some cases we may want to spend more time in atomic wait than
hardcoded 2us. Let's add additional fast timeout parameter to allow
flexible configuration of atomic timeout before switching into heavy wait.
Add also possibility to return registry value to avoid extra read.
v2: use explicit fast t
Waiting for the response status in scratch register can be done
using our generic function. Let's use it.
v2: rebased
Signed-off-by: Michal Wajdeczko
Suggested-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 26 +++
From: Daniele Ceraolo Spurio
In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).
v2: Align the instance types (Tvrtko)
v3: Don't use enums for bspec-defined stuff (Michal)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
This refactoring helps simplify a few things here and there.
Daniele Ceraolo Spurio (2):
drm/i915: Classify the engines in class + instance
drm/i915: Use the engine class to get the context size
Oscar Mateo (3):
drm/i915: Use the same vfunc for BSD2 ring init
drm/i915: Generate the engine
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Oscar Ma
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko, Chris)
- Make sure the mock engine name is null-terminated (Tvrtko, Chris)
v3: Because I'm stupid (Chris)
v4: Verify engine name wasn't truncate
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
If we needed to do something different for the init functions, we could
always look at the engine instance to make the distinction. But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwards).
With this, the init functions depen
On Fri, Apr 07, 2017 at 04:01:45PM +, Michal Wajdeczko wrote:
> Waiting for the response status in scratch register can be done
> using our generic function. Let's use it.
>
> v2: rebased
>
> Signed-off-by: Michal Wajdeczko
> Suggested-by: Tvrtko Ursulin
> Cc: Tvrtko Ursulin
> Cc: Joonas L
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Extend
intel_wait_for_register_fw() with fast timeout
URL : https://patchwork.freedesktop.org/series/22678/
State : success
== Summary ==
Series 22678v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
On Fri, Apr 07, 2017 at 02:15:45AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> In such a way that vcs and vcs2 are just two different instances (0 and 1)
> of the same engine class (VIDEO_DECODE_CLASS).
>
> v2: Align the instance types (Tvrtko)
>
> v3: Don't use enums for bspec
On Fri, Apr 07, 2017 at 02:15:47AM -0700, Oscar Mateo wrote:
> Not really needed, but makes the next change a little bit more compact.
>
> v2:
> - Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko,
> Chris)
> - Make sure the mock engine name is null-terminated (Tvrtko, Chri
On Fri, Apr 07, 2017 at 02:15:48AM -0700, Oscar Mateo wrote:
> There are some properties that logically belong to the engine class, and some
> that belong to the engine instance. Make it explicit.
>
> v2: Commit message (Tvrtko)
>
> v3:
> - Rebased
> - Exec/uabi id should be per instance (Chr
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
== Series Details ==
Series: Classify the engines in class + instance (rev5)
URL : https://patchwork.freedesktop.org/series/22535/
State : success
== Summary ==
Series 22535v5 Classify the engines in class + instance
https://patchwork.freedesktop.org/api/1.0/series/22535/revisions/5/mbox/
fi-
On Fri, Apr 07, 2017 at 02:34:54AM -0700, Oscar Mateo wrote:
> There are some properties that logically belong to the engine class, and some
> that belong to the engine instance. Make it explicit.
>
> v2: Commit message (Tvrtko)
>
> v3:
> - Rebased
> - Exec/uabi id should be per instance (Chr
From: Jose Abreu
HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.
These new blocks are:
- ycbcr420 video data (vdb) block: video modes which can be supported
only in ycbcr420 outpu
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
This patch series adds DRM layer support for YCBCR HDMI output handling.
The target HDMI YCBCR outputs are:
- YCBCR444
- YCBCR422
- YCBCR420
As YCBCR420 output is added in HDMI 2.0, this patch series also
contain few patches to handle new EDID extention blocks, added
for YCBCR420 modes (CEA-861-F)
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.
One of these new blocks is: ycbcr420 vcb
- ycbcr420 video capability data (vcb) block: video modes which can be
support in ycbcr420 o
This patch adds support for HDMI ycbcr outputs in i915 layer.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
Cc:
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
Cc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Sha
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI outp
To get a ycbcr420 output from intel platforms, there are two
major steps:
- RGB->YCBCR conversion using a pipe CSC.
- Program PIPE_MISC register to generate a ycbcr420 output.
- Scaling down YCBCR444 samples to YCBCR420 samples using a pipe
scaler.
This patch:
- Does scaler allocation for HDMI y
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI i
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, t
I thought I've fixed this, but maybe not. Anyway, clearly broken, and
easy fix.
Cc: Tony Lindgren
Reported-by: Tony Lindgren
Fixes: b95ff0319a82 ("drm: Remove drm_modeset_(un)lock_crtc")
Cc: Harry Wentland
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airli
== Series Details ==
Series: Classify the engines in class + instance (rev6)
URL : https://patchwork.freedesktop.org/series/22535/
State : success
== Summary ==
Series 22535v6 Classify the engines in class + instance
https://patchwork.freedesktop.org/api/1.0/series/22535/revisions/6/mbox/
Tes
1 - 100 of 134 matches
Mail list logo
