From: Vathsala Nagaraju
Prints live state of psr1.Extending the existing
PSR2 live state function to cover psr1.
Tested on KBL with psr2 and psr1 panel.
v2: rebase
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_debugfs.c | 67 ++
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin Ian King
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: intel-gfx@lists
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
Documentation/driver-api/dma-
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_fence.c b/drivers/gpu/drm/vc4/vc4_f
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/msm_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fenc
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 file changed, 7 deletions(-)
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
Signed-off-by: Daniel Vetter
Cc: Kees Cook
Cc: Cihangir Akturk
Cc: Sean Pa
It's a copy of dma_fence_default_wait, written slightly differently.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fence.c | 63 ---
1 file changed, 63
When this was introduced in
commit a519435a96597d8cd96123246fea4ae5a6c90b02
Author: Christian König
Date: Tue Oct 20 16:34:16 2015 +0200
dma-buf/fence: add fence_wait_any_timeout function v2
there was a restriction added that this only works if the dma-fence
uses the dma_fence_default_wai
Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.l
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 7 ---
drivers/gpu/drm/drm_syncobj.c
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ---
1 file changed, 7 delet
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Monk Liu
Cc: pding
Cc: Andrey Grodzovsky
Cc: Evan Quan
Cc: Daniel Vetter
Cc: Kees Cook
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 --
drivers/gpu/drm/amd/amdgp
Noticed while I was typing docs. Entirely unused.
Signed-off-by: Daniel Vetter
---
include/linux/dma-fence.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 9d6f39bf2111..f9a6848f8558 100644
--- a/include/linux/dma-fence.
Almost everyone uses dma_fence_default_wait.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence-array.c | 1 -
drivers/dma-buf/dma-fence.c | 5 -
drivers/dma-buf/sw_sync.
Hi all,
Somewhat motivated by me looking at the v3d patch I went and dug around
in the dma-fence code a bit. Result was a bit of doc polish and making a
bunch of callbacks optional for cases where most implementations wanted
the same default behaviour.
Comments, testing, feedback very much welcom
- Switch to inline member docs for dma_fence_ops.
- Mild polish all around.
- hyperlink all the things!
v2: - Remove the various [in] annotations, they seem really uncommon
in kerneldoc and look funny.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-.
On Wednesday 25 April 2018 06:26 AM, Dhinakaran Pandiyan wrote:
On Fri, 2018-04-20 at 17:14 +, Souza, Jose wrote:
On Fri, 2018-04-20 at 15:06 +0530, vathsala nagaraju wrote:
From: Vathsala Nagaraju
Prints live state of psr1.Extending the existing
PSR2 live state function to cover psr1.
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects:
capture stack traces at _init() time
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gnu
On Thu, Apr 26, 2018 at 02:39:04PM -0700, Tarun Vyas wrote:
> On Thu, Apr 26, 2018 at 10:47:40AM -0700, Dhinakaran Pandiyan wrote:
> >
> >
> >
> > On Thu, 2018-04-26 at 16:41 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> > > > From: Tar
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects:
capture stack traces at _init() time
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu
On Wed, Apr 25, 2018 at 02:53:25PM -0700, Rodrigo Vivi wrote:
> On Wed, Apr 25, 2018 at 02:47:35PM -0700, Souza, Jose wrote:
> > On Wed, 2018-04-25 at 14:40 -0700, Rodrigo Vivi wrote:
> > > On Wed, Apr 25, 2018 at 02:23:32PM -0700, José Roberto de Souza
> > > wrote:
> > > > This will be helpful to
On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> This reduces the spaghetti that intel_dp_aux_xfer().
>
> Moved doing less changes possible here, improvements to the new
> function in further patch.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> ---
>
On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> Sink will interrupt source when it have any problem saving or reading
> the remote frame buffer.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
>
> Changes from v1:
> - printing a
On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> eDP spec states that sink device will do a short pulse in HPD
> line when there is a PSR/PSR2 error that needs to be handled by
> source, this is handling the first and most simples error:
> DP_PSR_SINK_INTERNAL_ERROR.
>
> Signed
No functional changes in this patch.
The SDP Header is a generic header for secondary data packets for
both eDP and DP so call it dp_sdp_header. This header gets used for
different SDP types already defined.
Also header bytes 2 and 3 are secondary data packet specific header bytes.
So change the c
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/ac
Make life easier in upcoming patches by moving the context_pin and
context_unpin vfuncs into inline helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 20 ++---
drivers/gpu/drm/i915/i915_debugfs.c
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
On Thu, 2018-04-26 at 16:41 +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> > From: Tarun
> >
> > The Display scanline counter freezes on PSR entry. Inside
> > intel_pipe_update_start, once Vblank interrupts are enabled, we start
> > exitin
Quoting Michał Winiarski (2018-04-26 17:21:39)
> On Wed, Apr 11, 2018 at 01:03:46PM +0100, Chris Wilson wrote:
> > Even though we weren't injecting guilty requests to be reset, we could
> > still fall over the issue of resetting the same request too fast -- where
> > the GPU refuses to start again.
From: Ville Syrjälä
During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
On Wed, Apr 11, 2018 at 01:03:46PM +0100, Chris Wilson wrote:
> Even though we weren't injecting guilty requests to be reset, we could
> still fall over the issue of resetting the same request too fast -- where
> the GPU refuses to start again. (Although it is interesting to note that
> reloading t
On Thu, Apr 26, 2018 at 06:25:13PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > > > [1.176131] [drm:i9xx_g
On Thu, Apr 26, 2018 at 08:42:54AM -0700, Lucas De Marchi wrote:
> On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Apr 25, 2018 at
On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > > This became dead code w
Oscar Mateo writes:
> The default GAPZ arbitrer priority value at power-on has been found
> to be incorrect.
>
> v2: Now renamed to Wa_1405543622
>
> v3: Rebased on top of the WA refactoring
>
I have suggested that when implementing workarounds,
authors, for example, add
References: HSDES#14055
On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > GMBUS and AUX inter
On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with
> > > fb: size=800x600@32,
On Thu, 26 Apr 2018, Jani Nikula wrote:
> v2 of https://patchwork.freedesktop.org/series/41215/
And pushed the lot after the CI results. Thanks for the review!
BR,
Jani.
>
> Jani Nikula (7):
> drm/i915/dp: remove stale comment about bw constants
> drm/i915/dp: move link_bw and rate_select d
On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > GMBUS and AUX interrupts on gen4/g4x").
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Lucas
On Thu, 26 Apr 2018, Tvrtko Ursulin wrote:
> On 26/04/2018 12:35, Jani Nikula wrote:
>> Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
>> circumstances.
>>
>> v2: don't change device info dump (Chris)
>>
>> Cc: Tvrtko Ursulin
>> Cc: Mika Kuoppala
>> Signed-off-by: Jani Nikula
>>
On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with
> > fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> > [1.176161] [drm:i915_gem_ob
Oscar Mateo writes:
> Inherit workarounds from previous platforms that are still valid for
> Icelake.
>
> v2: GEN7_ROW_CHICKEN2 is masked
> v3:
> - Since it has been fixed already in upstream, removed the TODO
> comment about WA_SET_BIT for WaInPlaceDecompressionHang.
> - Squashed with th
On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with fb:
> size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] creating
> preallocated stolen ob
On Thu, Apr 26, 2018 at 04:10:45PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote:
> > This warning just started appearing during boot on a machine I upgraded
> > to 4.17-rc2. The warning seems to have been there since 2015, but it
> > has never trigge
Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to
11 bits. This patch make changes to use proper mask for ICL+ during
hardware ddb value readout.
Changes since V1:
- Use _MASK & _SHIFT macro (James)
Changes since V2:
- use kernel type u8 instead of uint8_t
Changes since V3:
ICL has two slices of DBuf, each slice of size 1024 blocks.
We should not always enable slice-2. It should be enabled only if
display total required BW is > 12GBps OR more than 1 pipes are enabled.
Changes since V1:
- typecast total_data_rate to u64 before multiplication to solve any
possible
This patch adds support to start tracking status of DBUF slices.
This is foundation to introduce support for enabling/disabling second
DBUF slice dynamically for ICL.
Changes Since V1:
- use kernel type u8 over uint8_t
Signed-off-by: Mahesh Kumar
Reviewed-by: James Ausmus
---
drivers/gpu/drm/
Patches in this series were originally part of series:
https://patchwork.freedesktop.org/series/36993/
Reposting it here after rebase
use kernel types u8/u16 etc instead of uint8_t
Changes:
- Rebase the series
Mahesh Kumar (3):
drm/i915/icl: track dbuf slice-2 status
drm/i915/icl: Enable 2n
On Mon, Apr 23, 2018 at 01:11:25PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> >
> >
> > On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> > >> From: Ankit Nautiyal
> > >>
>
== Series Details ==
Series: drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
URL : https://patchwork.freedesktop.org/series/42331/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8813_full =
== Summary - WARNING ==
Minor unknown changes coming wi
== Series Details ==
Series: drm/i915: Compile out engine debug for release
URL : https://patchwork.freedesktop.org/series/42327/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8812_full =
== Summary - WARNING ==
Minor unknown changes coming with Pa
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8810_full =
== Summary - WARNING ==
Minor unknown changes coming wi
On 2018-03-30 21:45, Daniele Ceraolo Spurio wrote:
On 30/03/18 08:42, Lis, Tomasz wrote:
On 2018-03-29 00:28, Chris Wilson wrote:
Quoting Lis, Tomasz (2018-03-28 17:06:58)
On 2018-03-28 01:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preemp
On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > > It's been a while
On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> GMBUS and AUX interrupts on gen4/g4x").
>
> Cc: Ville Syrjälä
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +--
> drivers/g
On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> From: Tarun
>
> The Display scanline counter freezes on PSR entry. Inside
> intel_pipe_update_start, once Vblank interrupts are enabled, we start
> exiting PSR, but by the time the scanline counter is read, we may not
> have
On Wed, Apr 25, 2018 at 02:57:57PM -0700, Dhinakaran Pandiyan wrote:
> Sink crc is calculated by the sink for static frames irrespective of
> what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
> case for sink crc, we don't really need the sink_crc_{start, stop} code.
>
> The s
On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum() (rev3)
URL : https://patchwork.freedesktop.org/series/40122/
State : failure
== Summary ==
Applying: drm: Don't pass the index to drm_property_add_enum()
error: patch failed: drivers/gpu/drm/drm_connector.c:1069
On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote:
> This warning just started appearing during boot on a machine I upgraded
> to 4.17-rc2. The warning seems to have been there since 2015, but it
> has never triggered before today.
Looks like we have bug open about this. I just asked for
On Thu, Apr 26, 2018 at 6:15 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > It's been a while since we introduced drm_dev{get/put} functions
>> > to replace referen
On Thu, Apr 26, 2018 at 03:41:57PM +0300, David Weinehall wrote:
> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> > As we are careful not to register external interfaces before the
> > internals are brought up, we are not dependent upon a synchronous
> > probing and can allow ourse
Quoting David Weinehall (2018-04-26 13:41:57)
> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> > As we are careful not to register external interfaces before the
> > internals are brought up, we are not dependent upon a synchronous
> > probing and can allow ourselves to be probed f
Hi Daniel,
On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> > It's been a while since we introduced drm_dev{get/put} functions
> > to replace reference/unreference in drm subsystem for the
> > consistency purpose. S
Reviewed-by: Stanislav Lisovskiy
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of
Lisovskiy, Stanislav [stanislav.liso
Cc: Maarten, Ville
On Mon, 23 Apr 2018, Dave Jones wrote:
> This warning just started appearing during boot on a machine I upgraded
> to 4.17-rc2. The warning seems to have been there since 2015, but it
> has never triggered before today.
>
> Dave
>
> [1.158500] fb: switching to intel
On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> As we are careful not to register external interfaces before the
> internals are brought up, we are not dependent upon a synchronous
> probing and can allow ourselves to be probed from a secondary thread
> during system bootup. We alre
== Series Details ==
Series: drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
URL : https://patchwork.freedesktop.org/series/42331/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8813 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref()
== Series Details ==
Series: drm/i915: Compile out engine debug for release
URL : https://patchwork.freedesktop.org/series/42327/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8812 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:
On Thu, 26 Apr 2018 15:58:19 +0530
Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref()
== Series Details ==
Series: drm/core: Remove drm_dev_unref() and it's uses
URL : https://patchwork.freedesktop.org/series/42325/
State : failure
== Summary ==
Applying: drm/core: Remove drm_dev_unref() and it's uses
error: Failed to merge in the changes.
Using index info to reconstruct a base
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8810 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/dp: remove stale comment about bw constants
Okay!
Commit: drm/i915/dp: move link_bw
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e404413cc8c9 drm/i915/dp: remove stale comment about bw constants
ff040231fec8 drm/i915/dp: move
On 26/04/2018 12:35, Jani Nikula wrote:
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.
v2: don't change device info dump (Chris)
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.
v2: don't change device info dump (Chris)
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Hi Dave,
This is my first pull request for v4.18. Only UAPI change is adding a generic
plane
alpha property, which replaces the driver specific ones in sun4i, rcar-du and
atmel-hclcdc.
drm-misc-next-2018-04-26:
drm-misc-next for v4.18:
UAPI Changes:
- Add support for a generic plane alpha prop
Hi Vaishali,
Thank you for the patch.
On Thursday, 26 April 2018 13:28:19 EEST Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> al
On Wed, Apr 25, 2018 at 11:47:28AM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-04-17 at 14:31 +0300, Imre Deak wrote:
> > Add documentation to gen9_set_dc_state() on what enabling a given DC
> > state means and at what point HW/DMC actually enters/exits these states.
> >
> > Cc: Jani Nikula
Quoting Patchwork (2018-04-26 11:18:58)
> == Series Details ==
>
> Series: RFC drm/i915: Switch to kernel context before idling at runtime
> URL : https://patchwork.freedesktop.org/series/42321/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4101 -> Patchwork_8809 =
The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive
It's been a while since we introduced drm_dev{get/put} functions
to replace reference/unreference in drm subsystem for the
consistency purpose. So, with this patch, let's just replace
all current use cases of drm_dev_unref() with drm_dev_put and remove
the function itself.
Coccinelle was used for
On 26/04/2018 09:16, Patchwork wrote:
== Series Details ==
Series: drm/i915: Use seqlock in engine stats (rev3)
URL : https://patchwork.freedesktop.org/series/38347/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8806 =
== Summary - SUCCESS ==
No re
Quoting Mika Kuoppala (2018-04-26 11:19:14)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-04-24 13:26:11)
> >> Chris Wilson writes:
> >>
> >> > Ideally, we want to atomically flush and disable the tasklet before
> >> > resetting the GPU. At present, we rely on being the only part to
On 26/04/18 11:00, Joonas Lahtinen wrote:
Quoting Lionel Landwerlin (2018-04-25 14:45:21)
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
== Series Details ==
Series: RFC drm/i915: Switch to kernel context before idling at runtime
URL : https://patchwork.freedesktop.org/series/42321/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4101 -> Patchwork_8809 =
== Summary - FAILURE ==
Serious unknown changes comin
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-04-24 13:26:11)
>> Chris Wilson writes:
>>
>> > Ideally, we want to atomically flush and disable the tasklet before
>> > resetting the GPU. At present, we rely on being the only part to touch
>> > our tasklet and serialisation of the reset proc
Chris Wilson writes:
> The majority of the engine state dumping is too voluminous to be useful
> outside of a controlled setup, though a few do accompany severe errors.
> Keep the debug dumps next to the errors, but hide the others behind a CI
> compile flag. This becomes more useful when adding
Quoting Chris Wilson (2018-04-11 13:03:46)
> Even though we weren't injecting guilty requests to be reset, we could
> still fall over the issue of resetting the same request too fast -- where
> the GPU refuses to start again. (Although it is interesting to note that
> reloading the driver is suffic
1 - 100 of 125 matches
Mail list logo
