This reverts commit c5cab0d5fc9aa1cf14c7bc7ea88c80155e46e22f.
Jani believes the noise is gone, so let's see whether it's really
gone, before we drop this hack.
Cc: "Saarinen, Jani"
Cc: Martin Peres
Signed-off-by: Daniel Vetter
---
net/sched/sch_generic.c | 7 +--
1 file changed, 1 inserti
== Series Details ==
Series: Revert "net/sch_generic: Shut up noise"
URL : https://patchwork.freedesktop.org/series/43878/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9136 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patch
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 29, 2018 12:27 PM
> To: C, Ramalingam
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wil
On Mon, May 28, 2018 at 03:26:48PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 10.42, skrev Daniel Vetter:
> > On Wed, May 23, 2018 at 04:34:06PM +0200, Noralf Trønnes wrote:
> > > This the beginning of an API for in-kernel clients.
> > > First out is a way to get a framebuffer backed by a dum
On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 11.16, skrev Daniel Vetter:
> > On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> > > This is the first step in getting generic fbdev emulation.
> > > A drm_fb_helper_funcs.fb_probe function is added
On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, May 29, 2018 12:27 PM
> > To: C, Ramalingam
> > Cc: intel-gfx@lists.freedesktop.org; dri-de...@li
On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote:
> On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
> >
> >
> > On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
> > > On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
> > > > Initialize HDCP2.2 support.
Oscar Mateo writes:
> Revert to the legacy implementation.
>
> v2: GEN7_ROW_CHICKEN2 is masked
> v3:
> - Rebased
> - Renamed to Wa_2006611047
> - A0 and B0 only
> v4:
> - Add spaces around '<<' (and fix the surrounding code as well)
> - Mark the WA as pre-prod
> v5: Rebased on top of th
Oscar Mateo writes:
> Redirects the state cache to the CS Command buffer section for
> performance reasons.
>
> v2: Rebased
> v3: Rebased on top of the WA refactoring
> v3: Added References (Mika)
>
> References: HSDES#1604325460
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
Reviewed-by: Mi
== Series Details ==
Series: Revert "net/sch_generic: Shut up noise"
URL : https://patchwork.freedesktop.org/series/43878/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9136_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (i386
defconfig) failed like this:
In file included from include/asm-generic/barrier.h:20:0,
from arch/x86/include/asm/barrier.h:86,
from include/linux/nospec.h:8,
from driv
On Tuesday 29 May 2018 02:12 PM, Daniel Vetter wrote:
On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote:
On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wr
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 29, 2018 2:01 PM
> To: C, Ramalingam
> Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; seanp...@chromium.org; chris@chris-
>
If we find a task that has already been selected for reaping, consider
that it may still free some memory. Currently, we skip such tasks
believing that we've already extracted as memory free pages as possible
from before hitting a livelock. In practice, at least on single user
systems deliberating
On 4 April 2018 at 16:26, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
> register access. This patch rewrites it to use only PMU.
>
> Only overall command streamer busyness and GPU global data such as power
> and freque
== Series Details ==
Series: RFT mm/oomkill: Don't skip the reaper
URL : https://patchwork.freedesktop.org/series/43884/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9137 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9137 need t
Oscar Mateo writes:
> Disable blend embellishment in RCC.
>
> Also, some other registers style fixed in passing.
>
> v2: Rebased on top of the WA refactoring
> v3: Added References (Mika)
> v4:
> - Fixed in B0
> - Mentioned style fixes in commit message
>
> References: HSDES#2006665173
> Cc:
== Series Details ==
Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
URL : https://patchwork.freedesktop.org/series/43865/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9138 =
== Summary - SUCCESS ==
No regressions found.
External URL
Lionel pointed out that INSTPM was context saved, at least from gen6,
not from gen9. The only caveat is that INSTPM is a masked register (the
upper 16bits are a write-enable mask, the lower 16bits the value to
change) and also contains a read-only counter bit (which counts flushes,
and so flip flop
== Series Details ==
Series: RFT mm/oomkill: Don't skip the reaper
URL : https://patchwork.freedesktop.org/series/43884/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9137_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9
Quoting Stephen Rothwell (2018-05-29 12:26:05)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (i386
> defconfig) failed like this:
Thanks for reporting. I've added a patch to fix the issue now.
I'll talk with our CI team about testing 32-bit building to try to
avo
== Series Details ==
Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
URL : https://patchwork.freedesktop.org/series/43865/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9138_full =
== Summary - WARNING ==
Minor unknown changes comin
Oscar Mateo writes:
> Enables blend optimization for floating point RTs
>
> v2: Rebased on top of the WA refactoring
> v3: Added References (Mika)
>
> References: HSDES#1406393558
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
Let's see if we can get away without whitelisting this,
Reviewed-
Oscar Mateo writes:
> Prevents an error in the GAM unit. Also known as WaGamTlbPendError
>
> References: HSDES#1406463099
> References: HSDES#1406465643
> Signed-off-by: Oscar Mateo
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> drivers/gpu/drm/i915/
FYI, we're setting this in Mesa :
https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130
https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67
I don't think we realized this was a privileged register.
Anuj: Maybe we can drop it?
-
Li
Oscar Mateo writes:
> The remaining WA patches that haven't been merged to date, plus
> two new ones (WaEnablePreemptionGranularityControlByUMD &
> Wa_1406463099).
>
> Oscar Mateo (11):
> drm/i915/icl: WaDisableImprovedTdlClkGating
> drm/i915/icl: WaEnableStateCacheRedirectToCS
> drm/i915/i
These patches enable P010, P012 and P016 formats for GLK and CNL.
These formats are similar to NV12 extending from 8 bits per channel
to 10, 12 and 16 bits per channel.
For user space components there is in IGT kms_available_modes_crc test
which can test these new modes, test need to be recompiled
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happen
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
Signed-off-by: Chr
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419..a7e9316 100644
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_display.c | 24 +-
drivers/gpu/drm/i915/intel_sprite.c | 39 +++-
2 files changed,
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 48
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been reset
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First c
== Series Details ==
Series: series starting with [1/5] drm/i915: Remove stale asserts from
i915_gem_find_active_request()
URL : https://patchwork.freedesktop.org/series/43892/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Remove stale asserts from i915_gem_find_
== Series Details ==
Series: series starting with [1/5] drm/i915: Remove stale asserts from
i915_gem_find_active_request()
URL : https://patchwork.freedesktop.org/series/43892/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4253 -> Patchwork_9139 =
== Summary - WARNING ==
== Series Details ==
Series: Enable P010, P012 and P016 formats for GLK/CNL
URL : https://patchwork.freedesktop.org/series/43891/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
28b8b10f6e1d drm: Add P010, P012, P016 format definitions and fourcc
-:28: WARNING:LONG_LINE: line ove
On 29/05/18 12:16, Chris Wilson wrote:
Lionel pointed out that INSTPM was context saved, at least from gen6,
not from gen9. The only caveat is that INSTPM is a masked register (the
upper 16bits are a write-enable mask, the lower 16bits the value to
change) and also contains a read-only counter bi
== Series Details ==
Series: Enable P010, P012 and P016 formats for GLK/CNL
URL : https://patchwork.freedesktop.org/series/43891/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Add P010, P012, P016 format definitions and fourcc
Okay!
Commit: drm/i915: Add P010, P012, P
== Series Details ==
Series: Enable P010, P012 and P016 formats for GLK/CNL
URL : https://patchwork.freedesktop.org/series/43891/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4253 -> Patchwork_9140 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_91
Quoting Michal Wajdeczko (2018-05-28 18:16:18)
> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
> those events are now handled by intel_guc_to_host_event_handler_mmio().
>
> We should not try to read it on MMIO action error as 1) we may be using
> different set of register
Hi,
On Fri, 25 May 2018 23:59:35 +0200, Oscar Mateo
wrote:
GuC interface has been redesigned (or cleaned up, rather) starting
with Gen11, as a stepping stone towards a new branching strategy
that helps maintain backwards compatibility with previous Gens, as
well as sideward compatibility with
On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-05-28 18:16:18)
SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
those events are now handled by intel_guc_to_host_event_handler_mmio().
We should not try to read it on MMIO action
Quoting Michal Wajdeczko (2018-05-29 16:10:44)
> On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2018-05-28 18:16:18)
> >> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
> >> those events are now handled by intel_guc_to_host_eve
On Tue, 29 May 2018 17:17:02 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2018-05-29 16:10:44)
On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson
wrote:
> Quoting Michal Wajdeczko (2018-05-28 18:16:18)
>> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host
and
>> th
Hi Dave,
One potential Spectre vector plugging patch, a NULL deref fix and
a DMI info fix reported by user.
This is still based on -rc6 as my flight was delayed last week to
the extent I missed possibility of sending the PR.
For 4.19, Rodrigo will be picking up drm-next after Jani is done
with 4
Op 29-05-18 om 15:28 schreef Juha-Pekka Heikkila:
> Add P010 definition, semi-planar yuv format where each component
> is 16 bits 10 msb containing color value. First come Y plane [10:6]
> followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
>
> Add P012 definition, semi-planar yuv format where each
Hi Dave,
Although we didn't have anything for you last week, we have a couple of
one-liners this week. Tomi is fixing a regression introduced in 4.17, and
Dhinakaran added a previously unsupported psr setup time which could be
affecting displays in the wild.
drm-misc-fixes-2018-05-29:
core: Add
== Series Details ==
Series: series starting with [1/5] drm/i915: Remove stale asserts from
i915_gem_find_active_request()
URL : https://patchwork.freedesktop.org/series/43892/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9139_full =
== Summary - FA
Quoting Patchwork (2018-05-29 18:53:25)
> == Series Details ==
>
> Series: series starting with [1/5] drm/i915: Remove stale asserts from
> i915_gem_find_active_request()
> URL : https://patchwork.freedesktop.org/series/43892/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes fro
On Fri, May 18, 2018 at 02:54:53PM +0530, Ramalingam C wrote:
> Support for Burst read in HW is added for HDCP2.2 compliance
> requirement.
>
> This patch enables the burst read for all the gmbus read of more than
> 511Bytes, on capable platforms.
>
> v2:
> Extra line is removed.
> v3:
> Macr
From: Ville Syrjälä
Add an immutable zpos property for all planes. The normal order
is (bottom to top): primary,sprite(s),cursor.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_sprite.c | 5 -
2 files changed, 12 insertio
From: Ville Syrjälä
On SKL+ the dst colorkey must be configured on the lower
plane that contains the colorkey. This is in contrast to
most earlier platforms where the dst colorkey is configured
on the plane above.
The hardware will peform dst keying only between two immediately
adjacent (in zord
From: Ville Syrjälä
VLV/CHV can change the z order between the primary and sprite planes
freely. Let's expose that capability by making the zpos property
mutable. The cursor plane is always on top, so the cursor zpos is
left as an immutable property.
The way the hardware is configured is a bit a
From: Ville Syrjälä
VLV/CHV sprites use the old plane C layout of the colorkey mask
register. Insted of 8 bit masks for each RGB component in the
lower bits, the register only has the per channel src key enable
bits. On g4x+ sprites those bits are 24,25,26 whereas on the
old plane C and VLV/CHV s
From: Ville Syrjälä
On VLV/CHV we can use the "src key window" bit on the primary plane to
implemnt sprite dst colorkeying. This is exactly the same mechanism that
would be used on gen2-4 for sprite C dst colorkeying as well.
The slight complication with this approach is that we have to adjust t
From: Ville Syrjälä
exa_wm_yuv_rgb.g5a is identical to exa_wm_yuv_rgb.g4a. Just use a
symlink intead of duplicating the whole file.
Signed-off-by: Ville Syrjälä
---
src/render_program/exa_wm_yuv_rgb.g5a | 99 +--
1 file changed, 1 insertion(+), 98 deletions(-)
From: Ville Syrjälä
Not all sprite planes support RGB565. Insrtead of hardcoding which
platforms have it let's ask the kernel instead.
Signed-off-by: Ville Syrjälä
---
src/sna/sna.h | 1 +
src/sna/sna_display.c | 76 ++
src/sna/sna
From: Ville Syrjälä
Starting from ~KBL planes can do NV12. Let's make use that
capability in the sprite Xv adaptor.
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_sprite.c | 57 +++---
1 file changed, 49 insertions(+), 8 deletions(-)
diff --git a/sr
From: Ville Syrjälä
Allow the client to select between BT.601 and BT.709 via the
XV_COLORSPACE port attribute with the textured Xv adaptor as well.
Since the BT.601 coefficients are currently hardcoded in the
yuv->rgb shader, let's just add a mostly duplicated shader with
hardcoded BT.709 coeffi
From: Ville Syrjälä
On SKL+ dst color keying only works between the first sprite and the
primary. We probably wante the first Xv port to be the first sprite
plane so that the user gets working colorkeying for the port that is
most likely to be used first. No way to get dst colorkeying with the
ot
From: Ville Syrjälä
Our current yuv->rgb shaders follow the BT.601 conversion formula.
Rename the shader sources to indicate that fact.
Signed-off-by: Ville Syrjälä
---
src/render_program/Makefile.am | 22 +++---
src/render_program/exa_wm_yuv_rgb.g5a
From: Ville Syrjälä
When we're trying to reinstate the colorkey we might fail on account of
the plane still being enable with a configuration that prevent the
use of colorkey. This happens easily with NV12 since the plane scaler
required by even unscaled NV12 is not compatible with colorkey.
To
From: Ville Syrjälä
Even unscaled NV12 needs the plane scaler on SKL+, so when
unscaled NV12 setplane fails we should still take the GPU
scaling fallback path.
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_sprite.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff
== Series Details ==
Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying
on SKL+
URL : https://patchwork.freedesktop.org/series/43902/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ab49b9e98274 drm/i915: Fix sprite destination colorkeying on SKL+
b0
== Series Details ==
Series: Enable P010, P012 and P016 formats for GLK/CNL
URL : https://patchwork.freedesktop.org/series/43891/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9140_full =
== Summary - WARNING ==
Minor unknown changes coming with Pa
== Series Details ==
Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying
on SKL+
URL : https://patchwork.freedesktop.org/series/43902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4254 -> Patchwork_9141 =
== Summary - SUCCESS ==
No regressio
On Tue, May 29, 2018 at 5:47 AM, Lionel Landwerlin
wrote:
> FYI, we're setting this in Mesa :
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130
> https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67
> I don't think we realized
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration pe
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/d
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i9
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
Hi all,
Another iteration that takes into account :
- Tvrtko's nits from v7 on patch 8
- Tvrtko's suggestion not to return EPERM when dynamic sseu is
disabled through sysfs. Instead store the requested value and
apply it when/if dynamic sseu becomes enabled.
- A pretty import
We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/intel
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev7)
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d23a6b481d4b drm/i915: Program RPCS for Broadwell
6540acb8de8b drm/i915: Record the sseu conf
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev7)
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Program RPCS for Broadwell
Okay!
Commit: drm/i915: Record the sseu configurati
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev7)
URL : https://patchwork.freedesktop.org/series/42285/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4254 -> Patchwork_9142 =
== Summary - SUCCESS ==
No regressions found.
External URL
On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote:
> DPCD 2009h "Synchronization latency in sink" has bits that tell us the
> maximum number of frames sink can take to resynchronize to source timing
> when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
> numb
On Tue, May 29, 2018 at 12:51:23PM -0700, Rodrigo Vivi wrote:
> On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote:
> > DPCD 2009h "Synchronization latency in sink" has bits that tell us the
> > maximum number of frames sink can take to resynchronize to source timing
> > when exiti
== Series Details ==
Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying
on SKL+
URL : https://patchwork.freedesktop.org/series/43902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4254_full -> Patchwork_9141_full =
== Summary - WARNING ==
Mi
On 25/05/18 08:14, Chris Wilson wrote:
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; f
Hi,
On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:
We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i9
The dpcd read during psr_dpcd_init may not always return the
requested number of bytes. No known cases yet, but good to
put that check in place.
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_psr.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
== Series Details ==
Series: drm/i915/psr: Check for partial PSR dpcd reads
URL : https://patchwork.freedesktop.org/series/43907/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e77d22f295bc drm/i915/psr: Check for partial PSR dpcd reads
-:23: CHECK:PARENTHESIS_ALIGNMENT: Alignme
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev7)
URL : https://patchwork.freedesktop.org/series/42285/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4254_full -> Patchwork_9142_full =
== Summary - FAILURE ==
Serious unknown changes com
== Series Details ==
Series: drm/i915/psr: Check for partial PSR dpcd reads
URL : https://patchwork.freedesktop.org/series/43907/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4255 -> Patchwork_9143 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_91
On Tue, 2018-05-29 at 12:51 -0700, Rodrigo Vivi wrote:
> On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote:
> >
> > DPCD 2009h "Synchronization latency in sink" has bits that tell us
> > the
> > maximum number of frames sink can take to resynchronize to source
> > timing
> > when
On 29/05/18 21:26, Michel Thierry wrote:
Hi,
On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:
We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.
Signed-off-by: L
Quoting Lionel Landwerlin (2018-05-29 22:35:08)
> On 29/05/18 21:26, Michel Thierry wrote:
> > Hi,
> >
> > On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:
> >> We want to be able to modify other context images from the kernel
> >> context in a following commit. To be able to do this we need to map
== Series Details ==
Series: drm/i915/psr: Check for partial PSR dpcd reads
URL : https://patchwork.freedesktop.org/series/43907/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4255_full -> Patchwork_9143_full =
== Summary - WARNING ==
Minor unknown changes coming with Pa
On Thu, May 24, 2018 at 05:43:24PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote:
> > > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote:
> > > >
> > > > From: Anusha Sri
This patch adds a new option to force the use of a module specified from
the command line. The force command expects a module name which will be
used on the target test (changing the standard behavior). This feature
can be useful for developers that have to create a new module since it
is possible
This patch fix the following gcc warnings:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement] [..]
igt_color_encoding.c:45:2: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement] [..]
igt_color_encoding.c: In function ‘ycbcr_to_rgb_
This patch fix the following gcc warning:
warning: ‘strncpy’ specified bound 32 equals destination size
[-Wstringop-truncation]
strncpy(data->name, name, PARAM_NAME_MAX_SZ);
This error happens due to the '\0' character appended by strncpy. Notice
that reduces by one in the total of bytes to be
Note that 'proc_path' parameter in __igt_lsof_fds receives a string
which was initialized with the size of PATH_MAX and the local variable
'path' has the same size, but it also have to append: '/', '\0', and the
directory name. This situation caused the warning described below.
warning: ‘%s’ direc
1 - 100 of 105 matches
Mail list logo
