Hello Haihao,
Sorry, but I've gotten my wires crossed a little.
I was advised here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507994
to report this bug upstream, and to do a bisect on the mainline kernel.
It seems I've jumped the gun reporting the issue here - I should have done the
> -Original Message-
> From: Daniel, Thomas
> Sent: Wednesday, October 21, 2015 23:11
> To: Daniel Vetter
> Cc: Chris Wilson; intel-gfx@lists.freedesktop.org; Belgaumkar, Vinay; Yang,
> Rong R
> Subject: RE: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for
> execbuffer
>
> > --
The main goal of this subtest is to trigger the following warning in
the function i915_gem_object_get_fence():
if (WARN_ON(!obj->map_and_fenceable))
To trigger this warning, the subtest first creates a Y-tiled object and
an associated framebuffer with the Y-fb modifier. Furthermore, to
pre
This is a partial port of the following patch from John Harrison's GPU
scheduler patch series: (patch sent to Intel-GFX with the subject line
"[Intel-gfx] [RFC 19/39] drm/i915: Added scheduler support to __wait_request()
calls" on Fri 17 July 2015)
Author: John Harrison
Date: Th
*** General ***
A recurring issue during long-duration operations testing of concurrent
rendering tasks with intermittent hangs is that context completion interrupts
following engine resets are sometimes lost. This becomes a real problem since
the hardware might have completed a previously hung con
From: Tim Gore
Simulated hangs, as used by drv_hangman and some other IGT tests, are not
handled correctly with the new per-engine hang recovery mode. This patch fixes
several issues needed to get them working in the execlist case.
1) The "simulated" hang is effected by not submitting a particul
1. The i915_wedged_set() function now allows for both legacy full GPU reset and
per-engine reset of one or more engines at a time:
a) Legacy hang recovery by passing 0.
b) Multiple engine hang recovery by passing in an engine flag mask
where bit 0 corresponds to engine
Final enablement patch for GPU hang recovery using watchdog timeout.
Added execbuf flag for watchdog timeout in DRM kernel interface.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_lrc.c | 6 ++
include/uapi/drm/i915_drm.h | 5 -
2 files changed, 6 insertions(+), 5 deletion
Added debugfs functions and embedded test infrastructure in the context event
interrupt handler for simulating the loss of context event interrupts so that a
context submission state inconsistency can be induced. This is useful for
testing the consistency checker pre-stage to the engine hang recove
Signed-off-by: Tomas Elf
---
Documentation/DocBook/gpu.tmpl | 476
drivers/gpu/drm/i915/i915_irq.c | 8 +-
2 files changed, 483 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index c05d7df..91b
This is the final enablement patch for per-engine hang recovery. It sets up
per-engine hang recovery to be used per default in favour of full GPU reset.
Legacy full GPU reset will no longer be the preferred mode of hang recovery and
will only be used as a fall-back in case of frequent hangs on indi
Use is_locked parameter in __i915_wait_request() to determine if a thread
should be forced to back off and retry or if it can continue sleeping. Don't
return -EIO from __i915_wait_request since that is bad for the upper layers,
only -EAGAIN to signify reset in progress. (unless the driver is termin
Defined trace points and sprinkled the usage of these throughout the
TDR/watchdog implementation.
The following trace points are supported:
1. trace_i915_tdr_gpu_recovery:
Called at the onset of the full GPU reset recovery path.
2. trace_i915_tdr_engine_recovery:
These new TDR-specific metrics have previously been added to
i915_hangcheck_info() in debugfs. During design review Chris Wilson asked for
these metrics to be added to the error state as well.
Signed-off-by: Tomas Elf
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h
This patch enables watchdog timeout hang detection as an entrypoint into the
driver error handler. This form of hang detection overrides the promotion logic
normally used by the periodic hang checker and instead allows for direct access
to the per-engine hang recovery path.
NOTE: I don't know if B
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows userland
applications to enable hang detection on individual batch buffers. The
detection mechanism itself is mostly bound to the hardware and the only thing
that the driver needs to do to support this form of hang
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows userland
applications to enable hang detection on individual batch buffers. The
detection mechanism itself is mostly bound to the hardware and the only thing
that the driver needs to do to support this form of hang
With the per-engine hang recovery path already in place this patch adds
per-engine hang detection by letting the periodic hang checker detect hangs on
individual engines and communicate this to the error handler. During hang
checking every engine is checked and the hang detection status for each en
Makes i915_gem_reset_ring_status() public for use from engine reset path in
order to replicate the same behavior as in full GPU reset but for a single
engine.
Signed-off-by: Tomas Elf
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c
GPU engine reset handshaking is something that is applicable to both full GPU
reset and engine reset, which is something that is part of the upcoming TDR
per-engine hang recovery patches. Break out the common engine reset
request/unrequest code (originally written by Mika Kuoppala) for reuse later
There used to be a work queue separating the error handler from the hang
recovery path, which was removed a while back in this commit:
commit b8d24a06568368076ebd5a858a011699a97bfa42
Author: Mika Kuoppala
Date: Wed Jan 28 17:03:14 2015 +0200
drm/i915: Remove
TDR = Timeout Detection and Recovery.
This change introduces support for TDR-style per-engine reset as an initial,
less intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. Initially we're only
supporting gen8 but adding suppor
i915_gem_wedge now returns a non-zero result in three different cases:
1. Legacy: A hang has been detected and full GPU reset is in progress.
2. Per-engine recovery:
a. A single engine reference can be passed to the function, in which
case only that engine will be checked. If tha
This patch series introduces the following features:
* Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode.
TDR is an umbrella term for anything that goes into detecting and recovering
from GPU hangs and is a term more widely used outside of the i915 driver.
This feature intro
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
reproduce: make htmldocs
All warnings (
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
config: x86_64-rhel (attached as .config
Hi Matt,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color-support-for-i915/20151023-082852
config: x86_64-randconfig-x005-10211812
Now that we've added an RGBA property type to the kernel that handles
RGBA values with a specific bit layout, let's add a userspace helper to
allow userspace to easily build values in the proper format.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matt Roper
---
xf86drmMode.c | 36
Tell the kernel that we understand atomic and want to have access to
atomic-only properties. If the kernel doesn't support atomic for i915
yet (and i915.nuclear_pageflip=1 isn't passed on the kernel command
line) this will silently fail, but won't cause any problems.
We wrap this in an #ifdef to
Update the existing test to use the current kernel interface, but leave
the test logic untouched. As the test is written at the moment it's
only really useful for manual testing...it will happily return success
even if we fail to set the background color (or misprogram the HW with
the wrong value)
Recent Intel platforms (SKL+) support a background canvas color below the
hardware planes. This background color can be seen on areas not covered by a
plane, or if we program the hardware with various plane blending modes.
Chandra Konduru previously took a stab at writing i915 patches to support
To support CRTC background color, we need a way of communicating RGB
color values to the DRM. However there is often a mismatch between how
userspace wants to represent the color value vs how it must be
programmed into the hardware; this mismatch can easily lead to
non-obvious bugs. Let's create
SKL and BXT allow CRTC's to be programmed with a background/canvas color
below the programmable planes. Let's expose this as a property to allow
userspace to program a desired value.
This patch is based on earlier work by Chandra Konduru; unfortunately
the driver has evolved so much since his pat
On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson wrote:
> Pinning a userptr onto the hardware raises interesting questions about
> the lifetime of such a surface as the framebuffer extends that life
> beyond the client's address space. That is the hardware will need to
> keep scanning out from the ba
On Thu, Oct 22, 2015 at 10:35 PM, wrote:
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index 04ca25b..f3c76ae 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void)
> * seems to fare better. We need to investigate what's going o
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 24
1 file changed, 24 insertions(+)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 48e9062..e1b5856 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -129,6 +129,28 @@ struct event_s
From: Ville Syrjälä
Do a dry run with rtcwake first to determine if the system even supports
the intended suspend state. If not, skip the test.
Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3.
Signed-off-by: Ville Syrjälä
---
lib/igt_aux.c | 6 ++
1 file changed, 6 insertio
From: Ville Syrjälä
Don't use the rounded vrefresh info to predict the frame duration.
Instead calculate if from the clock.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index a139d4
From: Ville Syrjälä
Don't try to test invaliud pipe/port combos. Fixes the test on
VLV w/ DSI since the pipe<->DSI port mapping is fixed. Should also
fix other platforms with similar restrictions.
Signed-off-by: Ville Syrjälä
---
tests/kms_pipe_crc_basic.c | 6 ++
1 file changed, 6 inserti
Em Qua, 2015-10-21 às 18:38 +0100, ch...@chris-wilson.co.uk escreveu:
> On Wed, Oct 21, 2015 at 05:32:16PM +, Zanoni, Paulo R wrote:
> > Em Qua, 2015-10-21 às 13:37 +0100, Chris Wilson escreveu:
> > > On Tue, Oct 20, 2015 at 11:49:53AM -0200, Paulo Zanoni wrote:
> > > > Don't try to list in com
On Wed, Oct 21, 2015 at 06:19:23PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-10-21 às 14:01 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:59AM -0200, Paulo Zanoni wrote:
> > > If we run igt/kms_frontbuffer_tracking, this message will appear
> > > thousands of times, eating a si
On Thu, Oct 22, 2015 at 01:54:17PM -0400, Alex Deucher wrote:
> On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter wrote:
> > I just realized that I've forgotten to update all the gem refcounting
> > docs. For pennance also add pretty docs for the overall drm_gem_object
> > structure, with a few links
On Fri, Oct 23, 2015 at 02:47:49AM +0800, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test WARNING on drm/drm-next -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Updat
Hi Dave,
Few more drm-misc stragglers for 4.4. Big thing is the generic probe for
imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing).
Also the hdmi clocking fixes from Ville which was a lot of confusion about
which tree it should be applied to ;-)
Cheers, Daniel
The foll
On Thu, Oct 22, 2015 at 07:26:36PM +, Zanoni, Paulo R wrote:
> Em Qui, 2015-10-22 às 09:52 +0200, Maarten Lankhorst escreveu:
> > Op 20-10-15 om 15:49 schreef Paulo Zanoni:
> > > We're going to kill intel_fbc_find_crtc(), that's why a big part of
> > > the logic moved from intel_fbc_find_crtc()
Em Qui, 2015-10-22 às 09:52 +0200, Maarten Lankhorst escreveu:
> Op 20-10-15 om 15:49 schreef Paulo Zanoni:
> > We're going to kill intel_fbc_find_crtc(), that's why a big part of
> > the logic moved from intel_fbc_find_crtc() to crtc_is_valid().
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > d
Hi Daniel,
[auto build test WARNING on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
config: x86_64-randconfig-s1-10230205 (att
On Thu, Oct 22, 2015 at 6:07 PM, Rodrigo Vivi wrote:
> regarding your offline question: yes, I had your patch applied here, so
>
> Tested-by: Rodrigo Vivi
>
> On Wed, Oct 21, 2015 at 7:57 AM, Patrik Jakobsson
> wrote:
>> The current CSR loading code depends on the CSR program memory to be
>> cle
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync
On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter wrote:
> I just realized that I've forgotten to update all the gem refcounting
> docs. For pennance also add pretty docs for the overall drm_gem_object
> structure, with a few links thrown in fore good.
>
> As usually we need to make sure the kerneldo
Hi Daniel,
[auto build test ERROR on drm/drm-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
config: i386-randconfig-s1-201542 (attached
On Thu, Oct 22, 2015 at 05:49:56PM +0100, Dave Gordon wrote:
> On 19/10/15 16:32, Tomas Elf wrote:
> >Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
> >concurrency problems between the context event interrupt handler and the
> >reset
> >path immediately following a GP
It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.
The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.
While at it add a note in the create_mmap_offset kerneldoc that
dri
A bunch of things have been removed meanwhile and docs not fully
brought up to speed. And a few gaps closed where I noticed missing
kerneldoc while reading through the overview sections.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 33 -
drive
I just realized that I've forgotten to update all the gem refcounting
docs. For pennance also add pretty docs for the overall drm_gem_object
structure, with a few links thrown in fore good.
As usually we need to make sure the kerneldoc reference is at most a
sect2 for otherwise it won't be listed.
On 19/10/15 16:32, Tomas Elf wrote:
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the reset
path immediately following a GPU reset.
* v2 (Chris Wilson):
Do execlist check and use simpler form of s
regarding your offline question: yes, I had your patch applied here, so
Tested-by: Rodrigo Vivi
On Wed, Oct 21, 2015 at 7:57 AM, Patrik Jakobsson
wrote:
> The current CSR loading code depends on the CSR program memory to be
> cleared after boot. This is unfortunately not true on all hardware.
>
On Thu, Oct 22, 2015 at 03:15:55PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 21/10/15 16:24, Chris Wilson wrote:
> >Our GPUs impose certain requirements upon buffers that depend upon how
> >exactly they are used. Typically this is expressed as that they require
> >a larger surface than would be
On ke, 2015-08-26 at 16:58 +0530, Animesh Manna wrote:
> From: Daniel Vetter
>
> This removes two anti-patterns:
> - Locking shouldn't be used to synchronize with async work (of any
> form, whether callbacks, workers or other threads). This is what the
> mutex_lock/unlock seems to have been f
Hi,
no more warnings with this patch.
Thank you!
Am 21.10.2015 um 16:22 schrieb Jani Nikula:
> commit 0706f17c307b056ff6f1848320ba82d76945a6ff
> Author: Egbert Eich
> Date: Wed Sep 23 16:15:27 2015 +0200
>
> drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2
>
> a
On Thu, Oct 22, 2015 at 04:50:05PM +0200, Maarten Lankhorst wrote:
> Op 22-10-15 om 15:30 schreef Ville Syrjälä:
> > On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote:
> >> By handling this after the atomic helper waits for vblanks there will
> >> be one less wait for vblank in the
Op 22-10-15 om 15:30 schreef Ville Syrjälä:
> On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote:
>> By handling this after the atomic helper waits for vblanks there will
>> be one less wait for vblank in the atomic path.
>>
>> Also get rid of the double wait_for_vblank on broadwell,
Hi,
On 21/10/15 16:24, Chris Wilson wrote:
Our GPUs impose certain requirements upon buffers that depend upon how
exactly they are used. Typically this is expressed as that they require
a larger surface than would be naively computed by pitch * height.
Normally such requirements are hidden away
On Thu, Oct 22, 2015 at 02:48:31PM +0100, Chris Wilson wrote:
> On Thu, Oct 22, 2015 at 04:31:01PM +0300, Mika Kuoppala wrote:
> > There is known issue on GT interrupt delivery with DC6 and
> > firmwares <1.21. There is a suspicion that this causes
> > spurious gpu hangs on driver init and with som
On Thu, Oct 22, 2015 at 03:42:58PM +0200, Maarten Lankhorst wrote:
> Op 22-10-15 om 15:08 schreef Daniel Vetter:
> > On Thu, Oct 22, 2015 at 01:56:27PM +0200, Maarten Lankhorst wrote:
> >> Parallel modesets are still not allowed, but this will allow updating
> >> a different crtc during a modeset i
On Thu, Oct 22, 2015 at 03:37:33PM +0200, Daniel Vetter wrote:
> On Thu, Oct 22, 2015 at 03:34:57PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Change FORCEWAKE & co. reads for the error state to use I915_READ_FW().
> > Reading a FORCEWAKE register using a function
On Thu, Oct 22, 2015 at 03:32:11PM +0200, Daniel Vetter wrote:
> On Thu, Oct 22, 2015 at 03:34:56PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > There's no need for __raw_i915_read8() & co. bot be macros, so make them
>
> s/bot/be
Actually s/bot/to/ :)
>
> > inl
On Thu, Oct 22, 2015 at 04:31:01PM +0300, Mika Kuoppala wrote:
> There is known issue on GT interrupt delivery with DC6 and
> firmwares <1.21. There is a suspicion that this causes
> spurious gpu hangs on driver init and with some workloads,
> as upgrading the firmware to 1.21 makes these problems
On Wed, Oct 21, 2015 at 06:41:46PM +0300, Mika Kuoppala wrote:
> From: Damien Lespiau
>
> Create a new debufs file for it, we'll have a few more things to add
> there.
>
> v2: Fix checkpatch warning about static const array
>
> Signed-off-by: Damien Lespiau (v1)
> Signed-off-by: Mika Kuoppala
On Thu, Oct 22, 2015 at 04:32:03PM +0300, Mika Kuoppala wrote:
> We have had one case where buggy csr/dmc firmware version influenced
> gt side and caused a hang. Add dmc firmware loading state and
> version to error state.
>
> v2: - Rebased on top of Damien's patches
> - included fw load stat
On Thu, Oct 22, 2015 at 03:35:00PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Include an early NEEDS_FORCEWAKE() check for vlv and chv.
> Hopefully that will avoid doing so many range checks in for many
> register accesses (at least for all display registers).
>
> Note
Op 22-10-15 om 15:08 schreef Daniel Vetter:
> On Thu, Oct 22, 2015 at 01:56:27PM +0200, Maarten Lankhorst wrote:
>> Parallel modesets are still not allowed, but this will allow updating
>> a different crtc during a modeset if the clock is not changed.
>>
>> Additionally when all pipes are DPMS off
On Thu, Oct 22, 2015 at 03:34:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Change the fw domain handling in the vlv/chv register read/write
> functions to look more like the SKL code, ie. have a single
> __force_wake_get() get call instead of multiple ones.
>
> Sign
On Thu, Oct 22, 2015 at 03:34:55PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> These patches fell off from my type safe register access series. I
> figured I'd post them separately since they're a fairly separate
> piece of work.
>
> Ville Syrjälä (5):
> drm/i915: Tur
On Thu, Oct 22, 2015 at 03:34:58PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
I even bothered to check whether you still have spaces in here ;-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
> 1 file
On Thu, Oct 22, 2015 at 03:34:57PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Change FORCEWAKE & co. reads for the error state to use I915_READ_FW().
> Reading a FORCEWAKE register using a function that can frob forcewake
> just seems wrong.
>
> There is a check to ski
There is known issue on GT interrupt delivery with DC6 and
firmwares <1.21. There is a suspicion that this causes
spurious gpu hangs on driver init and with some workloads,
as upgrading the firmware to 1.21 makes these problems
disappear.
As of now the current version included in distribution
firm
On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote:
> By handling this after the atomic helper waits for vblanks there will
> be one less wait for vblank in the atomic path.
>
> Also get rid of the double wait_for_vblank on broadwell, looks like
> it's a bug doing the vblank wait tw
On Thu, Oct 22, 2015 at 03:34:56PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There's no need for __raw_i915_read8() & co. bot be macros, so make them
s/bot/be
> inline funcitons. To avoid typo mistakes generate the inline functions
s/funcitons/functions/
> using pr
We have had one case where buggy csr/dmc firmware version influenced
gt side and caused a hang. Add dmc firmware loading state and
version to error state.
v2: - Rebased on top of Damien's patches
- included fw load state
v3: include dmc info only if platform supports it
Cc: Chris Wilson
Sign
We check these to determine firmware loading status. Include
them to help to debug causes of firmware loading fails.
v2: Move all CSR specific registers to i915_reg.h (Ville)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_reg.h | 10
On Thu, Oct 22, 2015 at 01:56:27PM +0200, Maarten Lankhorst wrote:
> Parallel modesets are still not allowed, but this will allow updating
> a different crtc during a modeset if the clock is not changed.
>
> Additionally when all pipes are DPMS off the cdclk will be lowered
> to the minimum allowe
On Thu, Oct 22, 2015 at 01:56:36PM +0200, Maarten Lankhorst wrote:
> This fixes a warning when the crtc is turned off. In that case fb
> will be NULL, and crtc_clock will be 0. Because the crtc is no longer
> active this is not a bug, and shouldn't trigger the WARN_ON.
>
> Also remove handling a n
On Thu, Oct 22, 2015 at 01:56:35PM +0200, Maarten Lankhorst wrote:
> On skylake some of the registers are only writable when the correct
> power wells are enabled. Because of this watermarks have to be updated
> before the crtc turns off, or you get unclaimed register read and write
> warnings.
>
On Thu, Oct 22, 2015 at 01:56:34PM +0200, Maarten Lankhorst wrote:
> I'm getting unclaimed register writes when checking the WM registers
> after the crtc is disabled. So I would imagine those are guarded by
> the crtc power well. Fix this by not reading out wm state when the
> power well is off.
>
Op 22-10-15 om 14:58 schreef Daniel Vetter:
> On Thu, Oct 22, 2015 at 01:56:26PM +0200, Maarten Lankhorst wrote:
>> Don't use plane->state directly, use the pointer from commit_plane.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_drv.h| 8 ++---
>> drivers/gpu/d
On Thu, Oct 22, 2015 at 01:56:28PM +0200, Maarten Lankhorst wrote:
> By handling this after the atomic helper waits for vblanks there will
> be one less wait for vblank in the atomic path.
>
> Also get rid of the double wait_for_vblank on broadwell, looks like
> it's a bug doing the vblank wait tw
On Thu, Oct 22, 2015 at 01:56:27PM +0200, Maarten Lankhorst wrote:
> Parallel modesets are still not allowed, but this will allow updating
> a different crtc during a modeset if the clock is not changed.
>
> Additionally when all pipes are DPMS off the cdclk will be lowered
> to the minimum allowe
On Thu, Oct 22, 2015 at 01:56:26PM +0200, Maarten Lankhorst wrote:
> Don't use plane->state directly, use the pointer from commit_plane.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_drv.h| 8 ++---
> drivers/gpu/drm/i915/intel_sprite.c | 67
>
On Thu, 22 Oct 2015, Ville Syrjälä wrote:
> On Thu, Oct 22, 2015 at 10:46:58AM +0300, Jani Nikula wrote:
>> On Wed, 21 Oct 2015, Ville Syrjälä wrote:
>> > On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote:
>> >> commit 0706f17c307b056ff6f1848320ba82d76945a6ff
>> >> Author: Egbert Eich
From: Ville Syrjälä
Change the fw domain handling in the vlv/chv register read/write
functions to look more like the SKL code, ie. have a single
__force_wake_get() get call instead of multiple ones.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_uncore.c | 37 +
From: Ville Syrjälä
Include an early NEEDS_FORCEWAKE() check for vlv and chv.
Hopefully that will avoid doing so many range checks in for many
register accesses (at least for all display registers).
Note that vlv already had the check in the write path since it shares
the gen6+ code for that.
S
From: Ville Syrjälä
These patches fell off from my type safe register access series. I
figured I'd post them separately since they're a fairly separate
piece of work.
Ville Syrjälä (5):
drm/i915: Turn __raw_i915_read8() & co. in to inline functions
drm/i915: Read FORCEWAKE registers with I91
From: Ville Syrjälä
Change FORCEWAKE & co. reads for the error state to use I915_READ_FW().
Reading a FORCEWAKE register using a function that can frob forcewake
just seems wrong.
There is a check to skip grabbing the forcewake for accessing FORCEWAKE
in intel_uncore.c, but there's no such check
From: Ville Syrjälä
There's no need for __raw_i915_read8() & co. bot be macros, so make them
inline funcitons. To avoid typo mistakes generate the inline functions
using preprocessor templates.
We have a few users of the raw register acces functions outside
intel_uncore.c, so let's also move the
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index dca0979..57af2c4 100644
--- a/drivers/gpu/drm/i915/in
Add Skylake Intel Graphics GT4 PCI IDs
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
include/drm/i915_pciids.h | 13 ++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
in
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8afda45..613bee2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -789,6 +789,8 @@ struct intel_device_info {
> > u8 num_sprites[I915_MAX_PIPES];
On Thu, Oct 22, 2015 at 10:46:58AM +0300, Jani Nikula wrote:
> On Wed, 21 Oct 2015, Ville Syrjälä wrote:
> > On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote:
> >> commit 0706f17c307b056ff6f1848320ba82d76945a6ff
> >> Author: Egbert Eich
> >> Date: Wed Sep 23 16:15:27 2015 +0200
> >>
I'm getting unclaimed register writes when checking the WM registers
after the crtc is disabled. So I would imagine those are guarded by
the crtc power well. Fix this by not reading out wm state when the
power well is off.
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/sh
1 - 100 of 128 matches
Mail list logo
