== Series Details ==
Series: series starting with [v3,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks
URL : https://patchwork.freedesktop.org/series/55097/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5405_full -> Patchwork_11286_full
==
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55095/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5405_full -> Patchwork_11285_full
Summary
---
**FAI
On Fri, Jan 11, 2019 at 07:08:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For bdw+ let's move the GAMMA_MODE write for the legacy LUT
> mode into the .load_luts() funciton directly, rather than
> relying on haswell_load_luts(). We'll be getting rid of
> haswell_load_luts() entirely
On Fri, Jan 11, 2019 at 07:08:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On g4x+ the pipe gamma enable bit for the primary plane affects
> the pipe bottom color as well. The same for the pipe csc enable
> bit on ilk+. Thus we must configure those bits correctly even
> when the pri
On Fri, Jan 11, 2019 at 07:08:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename some of the state variables in
> intel_plane_atomic_check_with_state() to make it less confusing.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_atomi
On Fri, Jan 11, 2019 at 07:08:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass the crtc state etc. as const to the color management commit
> functions. And while at it polish some of the local variables.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
> ---
> drivers
On Fri, Jan 11, 2019 at 07:08:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We shouldn't be computing gamma mode during the commit phase.
> Move it to the check phase.
>
> Signed-off-by: Ville Syrjälä
Looks like this also drops the posting reads, but I don't see anything
in the bs
== Series Details ==
Series: drm/i915/cmdparser: whitelist needed predicate registers for Anv (rev2)
URL : https://patchwork.freedesktop.org/series/55083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404_full -> Patchwork_11284_full
==
On 11/01/2019 18:40, Lionel Landwerlin wrote:
There is no reason not to whitelist those registers. In particular
MI_PREDICATE_RESULT can be loaded outside of MI_PREDICATE through
other registers to predicate other commands.
v2: Define MI_PREDICATE_DATA_UDW (Lionel)
Signed-off-by: Lionel Landwer
== Series Details ==
Series: drm/i915: Prevent concurrent GGTT update and use on Braswell (again)
URL : https://patchwork.freedesktop.org/series/55086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404_full -> Patchwork_11283_full
=
On Tue, Jan 08, 2019 at 01:07:33PM +0530, Uma Shankar wrote:
> Add the degamma and gamma lut sizes to gen11 capability
> structure.
>
> Note: Currently this doesn't account for the extended range gamma
> entries and this will be addressed with new segmented gamma ABI
> in a future patch.
>
> v2:
On Tue, Jan 08, 2019 at 01:07:32PM +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
== Series Details ==
Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB
BIOSen (rev2)
URL : https://patchwork.freedesktop.org/series/54942/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404_full -> Patchwork_11281_full
Dave, Daniel - any concerns if we merge this drm core patch through the
Intel tree? The second patch in the series doesn't apply cleanly in
drm-misc-next.
Matt
On Mon, Dec 17, 2018 at 02:44:14PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> c
On Tue, Jan 08, 2019 at 01:07:31PM +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
== Series Details ==
Series: Enable/disable gamma/csc dynamically and fix C8
URL : https://patchwork.freedesktop.org/series/55081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404_full -> Patchwork_11280_full
Summary
== Series Details ==
Series: series starting with [v3,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks
URL : https://patchwork.freedesktop.org/series/55097/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5405 -> Patchwork_11286
On 1/11/2019 09:31, Antonio Argenziano wrote:
On 11/01/19 00:22, Tvrtko Ursulin wrote:
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko
On 1/10/2019 02:11, Chris Wilson wrote:
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As t
== Series Details ==
Series: series starting with [v3,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks
URL : https://patchwork.freedesktop.org/series/55097/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7523c994baac drm/i915/psr: Allow PSR2 to be enabled when debu
This register contains how many blocks was sent in the past selective
updates.
Those registers are not kept set all the times but polling it after flip
can show the values corresponding to the last 8 frames.
v2: Improved macros(Dhinakaran)
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Reviewed-by: D
The old debugfs fields was not following a naming partern and it was
a bit confusing.
So it went from:
~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
Sink_Support: yes
PSR mode: PSR1
Enabled: yes
Busy frontbuffer bits: 0x000
Main link in standby mode: no
HW Enabled & Active bit: yes
Sour
The value of this registers will be used to test if PSR2 is doing
selective update and if the number of blocks match with the expected.
v2:
- Using new macros
- Changed the string output
v3:
- reading PSR2_SU_STATUS registers together(Dhinakaran)
- printing SU blocks of frames with 0 updates(Dhin
For now PSR2 is still disabled by default for all platforms but is
our intention to let debugfs to enable it for debug and tests
proporses, so intel_psr2_enabled() that is also used by debugfs to
decide if PSR2 is going to be enabled needs to take in consideration
the debug field.
v2: Using the sw
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55095/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5405 -> Patchwork_11285
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55095/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add a new "remapped" gtt_view
+drivers/gpu/drm/i915/i915_gem_gtt.c:3630:34:
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55095/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ff6533f795e4 drm/i915: Add a new "remapped" gtt_view
-:97: CHECK:LINE_SPACING: Please don't use multiple blank li
From: Ville Syrjälä
With gtt remapping in place we can use arbitrarily large
framebuffers. Let's bump the limits to 16kx16k on gen7+.
The limit was chosen to match the maximum 2D surface size
of the 3D engine.
With the remapping we could easily go higher than that for the
display engine. However
From: Ville Syrjälä
The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller strid
From: Ville Syrjälä
With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just arbitraily pick 256 KiB as the limit.
No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
(WaCompressedResourceDisplayNewHashMode:skl,kbl et
From: Ville Syrjälä
Add a live selftest to excercise rotated/remapped vmas. We simply
write through the rotated/remapped vma, and confirm that the data
appears in the right page when read through the normal vma.
Not sure what the fallout of making all rotated/remapped vmas
mappable/fenceable wou
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
v2: Use intel_remapped_plane_info base type
s/unused/unused_mbz/ (Chris)
Separate BUILD
From: Ville Syrjälä
Extend the rotated vma mock selftest to cover remapped vmas as
well.
TODO: reindent the loops I guess? Left like this for now to
ease review
v2: Include the vma type in the error message (Chris)
v3: Deal with trimmed sg
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Another year, another gtt remapping series.
Main changes:
- Actually trim the sg a bit
- Drop the earlier aligned viewport tricks since
they were there for ccs which we can't remap anyway
- Maybe something else I forgot already
Series available here:
git://github.com/vsyrj
== Series Details ==
Series: drm/i915/cmdparser: whitelist needed predicate registers for Anv (rev2)
URL : https://patchwork.freedesktop.org/series/55083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404 -> Patchwork_11284
== Series Details ==
Series: drm/i915: Prevent concurrent GGTT update and use on Braswell (again)
URL : https://patchwork.freedesktop.org/series/55086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404 -> Patchwork_11283
S
There is no reason not to whitelist those registers. In particular
MI_PREDICATE_RESULT can be loaded outside of MI_PREDICATE through
other registers to predicate other commands.
v2: Define MI_PREDICATE_DATA_UDW (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_cmd_parser.c
== Series Details ==
Series: drm/i915: Prevent concurrent GGTT update and use on Braswell (again)
URL : https://patchwork.freedesktop.org/series/55086/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
69d208d23911 drm/i915: Prevent concurrent GGTT update and use on Braswell
(agai
== Series Details ==
Series: drm/i915/cmdparser: whitelist needed predicate registers for Anv
URL : https://patchwork.freedesktop.org/series/55083/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/
== Series Details ==
Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB
BIOSen (rev2)
URL : https://patchwork.freedesktop.org/series/54942/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404 -> Patchwork_11281
==
On Braswell, under heavy stress, if we update the GGTT while
simultaneously accessing another region inside the GTT, we are returned
the wrong values. To prevent this we stop the machine to update the GGTT
entries so that no memory traffic can occur at the same time.
This was first spotted in
com
There is no reason not to whitelist those registers. In particular
MI_PREDICATE_RESULT can be loaded outside of MI_PREDICATE through
other registers to predicate other commands.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 6 +-
drivers/gpu/drm/i915/i915_reg.
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 are somewhat
bonkers and the DPLL is totally misprogrammed (P divider == 0).
That will result
== Series Details ==
Series: Enable/disable gamma/csc dynamically and fix C8
URL : https://patchwork.freedesktop.org/series/55081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5404 -> Patchwork_11280
Summary
---
**S
On 11/01/19 00:22, Tvrtko Ursulin wrote:
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko Ursulin wrote:
[snip]
Note about future inte
== Series Details ==
Series: Enable/disable gamma/csc dynamically and fix C8
URL : https://patchwork.freedesktop.org/series/55081/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
066d50880adb drm/i915: Clean up intel_plane_atomic_check_with_state()
43cec2bfb86d drm/i915: Split th
From: Ville Syrjälä
As with pipe gamma we can avoid the potential precision loss from
the pipe csc unit when there is no need to use it. And again
we need the same logic for updating the planes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 10 --
1 file changed
From: Ville Syrjälä
On pre-HSW gamma mode is configured via PIPECONF. The bits are
the same except shifted up, so we can reuse just store them in
crtc_state->gamma_mode in the HSW+ way, allowing us to share
some code later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h
From: Ville Syrjälä
Planes scanning out C8 will want to use the legacy lut as
their palette. That means the LUT content are unikely to
be useful for gamma correction on other planes. Thus we
should disable pipe gamma for all the other planes. And
we should reject any non legacy LUT configurations
From: Ville Syrjälä
The pipe internal precision is higher than what we currently program to
the degamma/gamma LUTs. We can get a higher quality image by bypassing
the LUTs when they're not needed. Let's do that.
Each plane has its own control bit for this, so we have to update
all active planes.
From: Ville Syrjälä
We shouldn't be computing gamma mode during the commit phase.
Move it to the check phase.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 44 +-
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm
From: Ville Syrjälä
Track whether pipe gamma is enabled or disabled. For now we
stick to the current behaviour of always enabling gamma. But
we do get working state readout for this now. On SKL+ we use
the pipe bottom color as our hardware state. On pre-SKL we
read the state back from the primary
From: Ville Syrjälä
On g4x+ the pipe gamma enable bit for the primary plane affects
the pipe bottom color as well. The same for the pipe csc enable
bit on ilk+. Thus we must configure those bits correctly even
when the primary plane is disabled.
To make the feasible let's split those settings fr
From: Ville Syrjälä
Just like we did for pipe gamma, let's also track the pipe csc
state. The hardware only exists on ILK+, and currently we always
enable it on hsw+ and never on any other platforms. Just like
with pipe gamma, the primary plane control register is used
for the readout on pre-SKL,
From: Ville Syrjälä
Split the color managemnt hooks along the single vs. double
buffered registers line. Of the currently progammed registers
GAMMA_MODE and the ilk+ pipe CSC are double buffered, the
LUTS and CHV CGM block are single buffered.
The double buffered register will be programmed duri
From: Ville Syrjälä
I figured I'd post this before we get too deep in the rabbit hole with
the icl stuff. This is just the first part of my color mgmt stuff I've
had cooking for far too long. The rest has to do with expanding the
support for higher precision gamma modes and the pipe csc to all
po
From: Ville Syrjälä
Rename some of the state variables in
intel_plane_atomic_check_with_state() to make it less confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 36 +++
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/dr
From: Ville Syrjälä
Pass the crtc state etc. as const to the color management commit
functions. And while at it polish some of the local variables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/intel_color.c | 128 ---
From: Ville Syrjälä
The LUTs are single buffered so we should program them after
the double buffered pipe updates have been latched by the
hardware.
We'll also fix up the IPS vs. split gamma w/a to do the IPS
disable like everyone else. Note that this is currently dead
code as we don't use the s
From: Ville Syrjälä
For bdw+ let's move the GAMMA_MODE write for the legacy LUT
mode into the .load_luts() funciton directly, rather than
relying on haswell_load_luts(). We'll be getting rid of
haswell_load_luts() entirely soon, and it's anyway cleaner
to have the GAMMA_MODE write in a single pla
>-Original Message-
>From: Roper, Matthew D
>Sent: Friday, January 11, 2019 3:57 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v5 1/6] drm/i915: Check for Null for color lut callbacks
>
>On Tue, Jan 0
>-Original Message-
>From: Roper, Matthew D
>Sent: Friday, January 11, 2019 4:08 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ;
>Sharma,
>Shashank
>Subject: Re: [v5 2/6] drm/i915: Sanitize crtc gamma mode
>
>On Tue, Jan 08, 2019 at 01:
On 08/01/2019 16:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a conte
== Series Details ==
Series: Enable Y2xx and Y4xx (xx:10/12/16 bits) packed formats for ICL
URL : https://patchwork.freedesktop.org/series/55035/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5401_full -> Patchwork_11279_full
===
On Fri, Jan 11, 2019 at 07:16:16AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Infoframe precompute/check (rev6)
> URL : https://patchwork.freedesktop.org/series/49983/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5397_full -> Patchwork_1127
On 11/01/2019 13:57, Chris Wilson wrote:
get_tiling == gem_get_tiling + igt_require; so do that instead of
opencoding the ioctl.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_tiled_wc.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff
On 11/01/2019 13:54, Chris Wilson wrote:
If we do not know the underlying swizzle on the HW, we do not know the
full tiling pattern and cannot predict the expected results. This is
often because the swizzle varies between pages and is not as constant as
we naively expected.
v2: gem_get_tiling()
get_tiling == gem_get_tiling + igt_require; so do that instead of
opencoding the ioctl.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_tiled_wc.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/tests/i915/gem_tiled_wc.c b/tests/i915
If we do not know the underlying swizzle on the HW, we do not know the
full tiling pattern and cannot predict the expected results. This is
often because the swizzle varies between pages and is not as constant as
we naively expected.
v2: gem_get_tiling() does the physical==reported check, we just
Chris Wilson writes:
> As we only release each power well once, we assume that each transcoder
> maps to a different domain. Complain if this is not so.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 ++
> 1
On 07/01/2019 11:28, Chris Wilson wrote:
If we do not know the underlying swizzle on the HW, we do not know the
full tiling pattern and cannot predict the expected results. This is
often because the swizzle varies between pages and is not as constant as
we naively expected.
Signed-off-by: Chris
On 08/01/2019 14:50, Chris Wilson wrote:
Currently blt-vs-render runs for a fixed loop count, and exceeds 360s
on a slow Skylake-y. It really doesn't tell us anything useful about low
likelihood events after the first few seconds it takes to fill memory,
so limit it to 30s (and hope that repeate
On 11.1.2019 7.30, swati2.sha...@intel.com wrote:
From: Swati Sharma
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
drivers/gpu/drm/i915/intel_sprite.c | 61 ++--
2 files changed, 89 insertions(+), 2 deletions(
The force option allows users to specify which driver they want that IGT
uses. Nonetheless, if the user has two or more loaded drivers in his
system, the force option will not work as expected because IGT will take
the first driver found at /dev/dri. This problem can be reproduced in a
QEMU VM that
Chris Wilson writes:
> On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
> transfer them to the runtime-pm code. We can use our wakeref tracking to
> verify that the wakeref is indeed passed from init to enable, and
> disable to fini; and across suspend.
>
> Signed-off-by: C
On 11-Jan-19 6:17 PM, Juha-Pekka Heikkila wrote:
On 11.1.2019 7.30, swati2.sha...@intel.com wrote:
From: Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies
On 11.1.2019 7.30, swati2.sha...@intel.com wrote:
From: Swati Sharma
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/
On 11.1.2019 7.30, swati2.sha...@intel.com wrote:
From: Swati Sharma
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: For each component, valid data occup
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev7)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5400_full -> Patchwork_11278_full
Summary
--
On 11/01/2019 10:35, Chris Wilson wrote:
sysfs doesn't give the driver an open() callback, so we can only report
the unavailability of HW on the first read; so check read() after checking
open().
Fixes: 93f0ad4b835e ("i915/hangman: Skip if disabled by the kernel")
Signed-off-by: Chris Wilson
-
== Series Details ==
Series: drm/i915/cnl: Fix CNL macros for Voltage Swing programming (rev2)
URL : https://patchwork.freedesktop.org/series/54092/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5400_full -> Patchwork_11277_full
sysfs doesn't give the driver an open() callback, so we can only report
the unavailability of HW on the first read; so check read() after checking
open().
Fixes: 93f0ad4b835e ("i915/hangman: Skip if disabled by the kernel")
Signed-off-by: Chris Wilson
---
tests/i915/hangman.c | 8 +++-
1 fil
On Mon, Jan 07, 2019 at 04:40:15PM +, Chris Wilson wrote:
> These exercise a certain HW misfeature, no longer protected by the
> kernel cmdparser due to obsolete userspace requirements.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> tests/intel-ci/blacklist.txt | 1 +
> 1 fil
On Thu, Jan 10, 2019 at 03:00:45PM +0100, Maarten Lankhorst wrote:
> Hi Dave/Daniel,
>
> Some patches were pushed today to drm-misc-fixes, and I think it would be nice
> if they are part of the pull req for v5.0-rc2. :)
>
> drm-misc-fixes-2019-01-10-1:
> Second pull request, drm-misc-fixes for v5
On Fri, Jan 11, 2019 at 11:18:22AM +0200, Jani Nikula wrote:
>
> Hi Dave & Daniel -
>
> drm-intel-fixes-2019-01-11:
> i915 fixes for v5.0-rc2:
> - Disable PSR for Apple panels
> - Broxton ERR_PTR error state fix
> - Kabylake VECS workaround fix
> - Unwind failure on pinning the gen7 ppgtt
> - GVT
Hi Dave & Daniel -
drm-intel-fixes-2019-01-11:
i915 fixes for v5.0-rc2:
- Disable PSR for Apple panels
- Broxton ERR_PTR error state fix
- Kabylake VECS workaround fix
- Unwind failure on pinning the gen7 ppgtt
- GVT workload request allocation fix
BR,
Jani.
The following changes since commit b
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko Ursulin wrote:
[snip]
Note about future interaction with preemption: Preemption could
h
87 matches
Mail list logo
