On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote:
>
> On Mon, 20 May 2019 18:11:07 +0200
> Daniel Vetter wrote:
>
> > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > > On Thu, 16 May 2019 14:24:55 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Thu, May 16, 2019 at 11:2
Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
> From: Tvrtko Ursulin
>
> gem_wsim uses the sw_fence timeline and confuses the script.
>
> v2:
> * Check the correct timeline as well. (Chris)
>
> Signed-off-by: Tvrtko Ursulin
> ---
> scripts/trace.pl | 3 +++
> 1 file changed, 3 insertions(+)
>
Quoting Tvrtko Ursulin (2019-05-20 15:47:24)
> @@ -999,30 +1092,53 @@ prepare_workload(unsigned int id, struct workload
> *wrk, unsigned int flags)
> /*
> * Identify if contexts target specific engine instances and if they
> * want to be balanced.
> +*
> +
On Fri, 17 May 2019, Chris Wilson wrote:
> Quoting Daniele Ceraolo Spurio (2019-05-17 16:27:26)
>>
>>
>> On 5/16/19 3:42 PM, Chris Wilson wrote:
>> > Quoting Chris Wilson (2019-05-16 23:10:10)
>> >> Quoting Chris Wilson (2019-05-16 23:07:43)
>> >>> Quoting Daniele Ceraolo Spurio (2019-05-16 22:5
On 04/29/2019 06:03 PM, Chris Wilson wrote:
> Quoting Xiaolin Zhang (2019-04-29 04:10:54)
>> +static void pv_submit(struct intel_engine_cs *engine)
>> +{
>> + struct intel_engine_execlists * const execlists = &engine->execlists;
>> + struct execlist_port *port = execlists->port;
>> +
On Tue, 21 May 2019, "Saarinen, Jani" wrote:
> HI,
>
>> -Original Message-
>> From: Vivi, Rodrigo
>> Sent: tiistai 21. toukokuuta 2019 3.12
>> To: Saarinen, Jani
>> Cc: Swarup, Aditya ; Gupta, Anshuman
>> ; Vetter, Daniel ; intel-
>> g...@lists.freedesktop.org; Syrjala, Ville ; Peres,
>
On 21/05/2019 09:14, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-20 15:47:24)
@@ -999,30 +1092,53 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
/*
* Identify if contexts target specific engine instances and if they
* want to
On Thu, 16 May 2019, Daniele Ceraolo Spurio
wrote:
> As a first step towards updating the code to work on the runtime_pm
> structure instead of i915, rework all the internals to use and pass
> around that.
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/i915_drv.h
On Tue, 21 May 2019 09:52:50 +0200
Daniel Vetter wrote:
> On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote:
> >
> > On Mon, 20 May 2019 18:11:07 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > > > On Thu, 16 May 2019 14:24:55
On Tue, May 21, 2019 at 12:01:29PM +0300, Pekka Paalanen wrote:
> Hi Daniel,
>
> what says the assumption of the only monitor being driven by CRTC 0
> was a bad one? :-p
>
> It's probably not obvious that userspace needs to explicitly try to
> avoid invalid configuration combinations by inspectin
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not al
Hello Jani,
On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> On Mon, 20 May 2019, Gwan-gyeong Mun wrote:
> > VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
> > Packet). In order to generalize SDP packet structure name, it renames
> > struct edp_vsc_psr to
On 2019/05/21 19:06, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in th
On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used
On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_start/end()
^Typo in subject.
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> For some reasons the pm_vt_switch_unregister call was missing from the
> direct unregister_framebuffer path. Fix this.
>
> v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
> called already. I botched that in v1
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> Create a new wrapper function for this, feels like there's some
> refactoring room here between the two modes.
>
> Signed-off-by: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Ve
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver and
the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI change will break the existing stack because negative values
are treated as 1, won't it?
On 5/20/2019
On 2019/05/21 19:51, Michal Hocko wrote:
> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
>> On 2019/05/21 19:06, Daniel Vetter wrote:
>>> In some special cases we must not block, but there's not a
>>> spinlock, preempt-off, irqs-off or similar critical section already
>>> that arms the might_sleep(
On Tue, 21 May 2019 13:04:12 +0200, Ye, Tony wrote:
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver and
the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI change will break the existing stack because ne
On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> On 2019/05/21 19:51, Michal Hocko wrote:
> > On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> >> On 2019/05/21 19:06, Daniel Vetter wrote:
> >>> In some special cases we must not block, but there's not a
> >>> spinlock, preempt-off, irqs-off or similar
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> It's not pretty.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Hans de Goede
> Cc: Yisheng Xie
> ---
> drivers/video/fbdev/core/fbcon.c | 19 +++
> 1 file changed, 19 insertions(+)
>
>
On 2019/05/21 20:11, Michal Hocko wrote:
> On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
>> On 2019/05/21 19:51, Michal Hocko wrote:
>>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
On 2019/05/21 19:06, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
== Series Details ==
Series: drm/i915: add i2c symlink under hdmi connector (rev2)
URL : https://patchwork.freedesktop.org/series/60866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110 -> Patchwork_13053
Summary
---
== Series Details ==
Series: drm: Allow modeset on unregisted connectors unconditionally (rev2)
URL : https://patchwork.freedesktop.org/series/60871/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110 -> Patchwork_13054
Sum
On Tue, 2019-05-21 at 13:14 +0300, Laurent Pinchart wrote:
> Hello Jani,
>
> On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> > On Mon, 20 May 2019, Gwan-gyeong Mun
> > wrote:
> > > VSC SDP Payload for PSR is one of data block type of SDP
> > > (Secondaray Data
> > > Packet). In ord
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
Video_Stream_Conf
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr4
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
Quoting Zhenyu Wang (2019-05-21 09:24:08)
>
> Hi,
>
> Here's gvt-fixes for 5.2-rc. It contains vgpu reset fix with
> proper timeline handling, fixes for guest TRTT setting which
> should be handled in context state instead of pushing directly
> to hardware and one error return fix.
This is now p
On Tue, May 21, 2019 at 12:56:30PM +0200, Maarten Lankhorst wrote:
> Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> > Create a new wrapper function for this, feels like there's some
> > refactoring room here between the two modes.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Lee Jones
> > Cc: Da
The SINGLE_TIMELINE flag can be used to create a context such that all
engine instances within that context share a common timeline. This can
be useful for mixing operations between real and virtual engines, or
when using a composite context for a single client API context.
Signed-off-by: Chris Wi
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
Having hid the partially exposed new ABI from the PR, put it back again
for completion of context recovery. A significant part of context
recovery is the ability to reuse as much of the old context as is
feasible (to avoid expensive reconstruction). The biggest chunk kept
hidden at the moment is fi
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that w
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context
Allow the user to direct which physical engines of the virtual engine
they wish to execute one, as sometimes it is necessary to override the
load balancing algorithm.
v2: Only kick the virtual engines on context-out if required
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
>
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
We also have an incoming patch where the Fixes: line has a comment in
it. Does your tooling account for this when checking the Fixes: line?
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
On 21/05/2019 08:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
From: Tvrtko Ursulin
gem_wsim uses the sw_fence timeline and confuses the script.
v2:
* Check the correct timeline as well. (Chris)
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 3 +++
1 file
On Mon, May 20, 2019 at 04:25:41PM -0700, Khaled Almahallawy wrote:
> According to DP 1.4 standard, if the source supports four pre-emphasis
> levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only
> when trasmitter programmed PRE-EMPHASIS_SET field (bits 4:3) to 11b (Level
On 14-May-19 9:40 PM, Ville Syrjälä wrote:
On Tue, May 14, 2019 at 03:13:21PM +0530, Swati Sharma wrote:
v3: -Rebase
v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
-Added the default label above the correct label [Jani]
-Corrected smatch warn "variable derefe
Hi Tvrtko,
On Mon, May 20, 2019 at 03:47:36PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of hardcoding the VCS balancing engines, discover, both with the
> new engines query, or with the legacy get_param in the fallback case, so
> class based addressing always works.
>
> v2
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
Reporting this version will help application figure out what level of
the support the running kernel provides.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 20
2 files changed, 23 insertions(+)
diff --git a
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
Hi all,
This small (but maybe not to everybody's taste) series enables us to
support performance queries on Vulkan. We've gone through the process
to define this as a Vulkan INTEL extension (it should appear on [1]
soonish).
We'll publish the Mesa side shortly.
Cheers,
[1] : https://github.com
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting f
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ee90db0cb06a dr
On Tue, May 21, 2019 at 08:24:53PM +0900, Tetsuo Handa wrote:
> On 2019/05/21 20:11, Michal Hocko wrote:
> > On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> >> On 2019/05/21 19:51, Michal Hocko wrote:
> >>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter wrot
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6113 -> Patchw
On Tue 21-05-19 14:43:38, Cristopher Lameter wrote:
> On Tue, 21 May 2019, Daniel Vetter wrote:
>
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_sta
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not al
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote:
> On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a n
On Tue, 21 May 2019, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
Just putting preempt on/of
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
URL : https://patchwork.freedesktop.org/series/60886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ade394d0944 linux-next: manual merge of the drm-misc tree with Linus' tree
-:1
On Mon, May 20, 2019 at 10:37:53AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.05.19 um 10:33 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.05.19 um 10:21 schrieb Daniel Vetter:
> > ...
> >> diff --git a/drivers/video/fbdev/core/fbmem.c
> >> b/drivers/video/fbdev/core/fbmem.c
> >> index fc3
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
URL : https://patchwork.freedesktop.org/series/60886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13056
Quoting Tvrtko Ursulin (2019-05-21 14:22:18)
>
> On 21/05/2019 08:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
> >> From: Tvrtko Ursulin
> >>
> >> gem_wsim uses the sw_fence timeline and confuses the script.
> >>
> >> v2:
> >> * Check the correct timeline as well. (C
== Series Details ==
Series: kernel.h: Add non_block_start/end()
URL : https://patchwork.freedesktop.org/series/60896/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
945d83c6e58d kernel.h: Add non_block_start/end()
-:77: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement
On Mon, May 20, 2019 at 11:39:44PM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() cal
On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> This is a similar idea to the fs_reclaim fake lockdep lock. It's
> fairly easy to provoke a specific notifier to be run on a specific
> range: Just prep it, and then munmap() it.
>
> A bit harder, but still doable, is to provoke the
On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i
== Series Details ==
Series: kernel.h: Add non_block_start/end()
URL : https://patchwork.freedesktop.org/series/60896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13057
Summary
---
**SUCCESS**
On Thu, 2019-05-16 at 15:40 -0700, Daniele Ceraolo Spurio wrote:
>
>
> > --- a/drivers/gpu/drm/i915/gt/intel_sseu.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
> > @@ -9,16 +9,18 @@
> >
> > #include
> > #include
> > +#include
>
> AFAICS this header is not needed anymore. With it rem
On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
>
> On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> > range: Just prep it, and then munm
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev4)
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13058
Summary
---
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0ef328fc3f6f drm/i915: Restore control over ppgtt for
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Restore control o
On Tue, May 21, 2019 at 06:00:36PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
> >
> > On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > > fairly easy to provoke a specifi
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13059
=
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index f263a8374273..2ad95977f7a8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2085,7 +2085,7 @@ stati
== Series Details ==
Series: drm/i915: Vulkan performance query support
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9577e457931d drm/i915/perf: introduce a versioning of the i915-perf uapi
3744cae4f12a drm/i915/perf: allow
== Series Details ==
Series: drm/i915: Vulkan performance query support
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: introduce a versioning of the i915-perf uapi
Okay!
Commit: drm/
From: Ville Syrjälä
The pcode mailbox has two data registers. So far we've only ever used
the one, but that's about to change. Expose the second data register to
the callers of sandybridge_pcode_read().
Signed-off-by: Ville Syrjälä
Reviewed-by: Clint Taylor
Reviewed-by: Radhakrishna Sripada
R
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query
Quoting Lionel Landwerlin (2019-05-21 15:08:53)
> Here we introduce a mechanism by which the execbuf part of the i915
> driver will be able to request that a batch buffer containing the
> programming for a particular OA config be created.
>
> We'll execute these OA configuration buffers right befo
On Mon, May 06, 2019 at 04:48:01PM +0300, Jani Nikula wrote:
> The i915.alpha_support module parameter has caused some confusion along
> the way. Add new i915.force_probe parameter to specify PCI IDs of
> devices to probe, when the devices are recognized but not automatically
> probed by the driver
On 21/05/2019 17:36, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977f7a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_l
On 21/05/2019 17:43, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:53)
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these O
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
> + if (eb->oa_config &&
> + eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the oa_config is not ordered with respect to requests, and the
registers changed here are not context saved and so may be changed by a
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6712c9a81334 dummycon: Sprinkle locking checks
-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal
== Series Details ==
Series: drm/i915: add i2c symlink under hdmi connector (rev2)
URL : https://patchwork.freedesktop.org/series/60866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110_full -> Patchwork_13053_full
Summar
Quoting Lionel Landwerlin (2019-05-21 17:50:30)
> On 21/05/2019 17:36, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> index f263a8374273..2ad95977f7a8 100644
> >> --- a/dr
On 21/05/2019 18:07, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
+ if (eb->oa_config &&
+ eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the oa_config is not ordered with respect to requests, and the
registers changed here are not c
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: dummycon: Sprinkle locking checks
Okay!
Commit: fbdev: locking check for fb_set_suspend
Oka
== Series Details ==
Series: drm: Allow modeset on unregisted connectors unconditionally (rev2)
URL : https://patchwork.freedesktop.org/series/60871/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110_full -> Patchwork_13054_full
===
== Series Details ==
Series: drm/i915: Vulkan performance query support
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13060
Summary
---
**FAILUR
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13061
Summary
---
**FAILURE**
Seriou
Quoting Lionel Landwerlin (2019-05-21 18:19:50)
> On 21/05/2019 18:07, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:54)
> >> + if (eb->oa_config &&
> >> + eb->oa_config !=
> >> eb->i915->perf.oa.exclusive_stream->oa_config) {
> > But the oa_config is not orde
1 - 100 of 136 matches
Mail list logo
