Re: [Intel-gfx] [PATCH] drm/i915: Fix crash when failing to parse MIPI VBT

On 7/24/2014 7:46 PM, rafael.barba...@intel.com wrote: From: Rafael Barbalho This particular nasty presented itself while trying to register the intelfb device (intel_fbdev.c). During the process of registering the device the driver will disable the crtc via i9xx_crtc_disable. These will also d

Re: [Intel-gfx] [PATCH 00/11]: Color manager framework for I915 driver

Thanks for your time, and review comments Matt. I appreciate the suggestions by you, Daniel. But I need a few more details, and I have a few concerns with the design you suggest, please find my comments inline. Regards Shashank On 7/25/2014 6:13 AM, Matt Roper wrote: On Thu, Jul 24, 2014 at 0

Re: [Intel-gfx] [RFC v2 1/1] drm/i915: Power gating display wells during i915_pm_suspend

On 23 July 2014 15:11, Daniel Vetter wrote: > On Sat, Jul 12, 2014 at 10:02:27AM +0530, sagar.a.kam...@intel.com wrote: >> From: Borun Fu >> >> On VLV, after i915_pm_suspend display power wells are staying >> power ungated. So, after initiating mem sleep "echo mem > /sys/power/state" >> Display i

Re: [Intel-gfx] [PATCH] NEWS: Updates

On Wed, Jul 23, 2014 at 10:32:43PM +0200, Daniel Vetter wrote: > --- > NEWS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/NEWS b/NEWS > index 1b5ee83ec849..4866d59b5619 100644 > --- a/NEWS > +++ b/NEWS > @@ -10,6 +10,12 @@ Release 1.8 (-xx-xx) > > - As usual piles of new t

Re: [Intel-gfx] [PATCH 00/11]: Color manager framework for I915 driver

On Thu, Jul 24, 2014 at 04:08:41AM +, Sharma, Shashank wrote: > Hi Daniel, > Thanks for your time and comments. > > The current design is exactly same as we discussed previously in the mail > chain, color manager is just the framework which does this job: > 1. Create a DRM property for re

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Register pipe level color properties

On Wed, Jul 23, 2014 at 11:34:56PM +0530, shashank.sha...@intel.com wrote: > From: Shashank Sharma > > In valleyview we have two pipe level color correction > properties: > 1. CSC correction (wide gamut) > 2. Gamma correction > > What this patch does: > 1. This patch adds software infrastructure

[Intel-gfx] [PATCH 07/12] Add intel_flush to abstract flushing pending acceleration operations

intel_flush flushes any pending acceleration operations to the hardware, just like intel_uxa_batch_submit does today except that it is not uxa-specific. Signed-off-by: Keith Packard --- src/uxa/intel.h | 3 +++ src/uxa/intel_display.c | 11 +++ src/uxa/intel_driver.c | 14 +

[Intel-gfx] [PATCH 08/12] Get rid of glamor stubs in intel_glamor.h

This eliminates the stubs in intel_glamor.h and replaces them with ifdefs instead. Signed-off-by: Keith Packard --- src/uxa/intel_dri.c | 20 ++-- src/uxa/intel_driver.c | 6 ++ src/uxa/intel_glamor.h | 21 - src/uxa/intel_present.c | 2 ++ src/uxa

[Intel-gfx] [PATCH 11/12] Add "none" acceleration option

This just uses fb directly Signed-off-by: Keith Packard --- configure.ac| 24 - src/Makefile.am | 9 +- src/intel_module.c | 12 ++- src/uxa/Makefile.am | 46 ++--- src/uxa/intel.h | 5 + src/uxa/intel_display.c | 6 ++ src/uxa/intel_dri3.c

[Intel-gfx] [PATCH 12/12] Delay initial modeset until root window contents are prepared

Wait until the root window has been painted for the first time before doing the modeset. This avoids flashing black while the root window gets set up. Signed-off-by: Keith Packard --- src/uxa/intel.h | 2 ++ src/uxa/intel_display.c | 39 ++- src/uxa/i

[Intel-gfx] [PATCH 09/12] Do more checks for proposed flip pixmaps

Make sure the pitch and tiling are correct. Make sure there's a BO we can get at. Signed-off-by: Keith Packard --- src/uxa/intel_present.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c index c53d71d..b901fb1 100644 --- a

[Intel-gfx] [PATCH 06/12] Remove glamor support from UXA acceleration

Makes UXA no longer include calls to glamor acceleration functions. Signed-off-by: Keith Packard --- src/uxa/Makefile.am| 9 -- src/uxa/intel_dri.c| 60 + src/uxa/intel_driver.c | 1 - src/uxa/intel_uxa.c| 49 --- src/uxa/intel_uxa.h| 1 - src/uxa/uxa-

[Intel-gfx] [PATCH 01/12] Stop trying to out-guess mesa for BO allocation

--- src/uxa/intel_uxa.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/uxa/intel_uxa.c b/src/uxa/intel_uxa.c index b396188..717754f 100644 --- a/src/uxa/intel_uxa.c +++ b/src/uxa/intel_uxa.c @@ -758,6 +758,7 @@ free_priv: goto free_priv; } +#if

[Intel-gfx] [PATCH 03/12] Don't use GetScratchPixmapHeader for shadow pixmaps

GetScratchPixmapHeader should only be used for local memory pixmaps, as used by PutImage and friends. That's because when you free the scratch pixmap header, it doesn't actually free the pixmap; instead, it gets stuffed in pScreen->pScratchPixmap and any private data stored on it will be left hangi

[Intel-gfx] [PATCH 10/12] Add glamor back into the driver

This adds glamor support back into the driver, but instad of going through UXA, this uses it directly instead. Signed-off-by: Keith Packard --- src/uxa/intel.h | 17 +++ src/uxa/intel_display.c | 30 - src/uxa/intel_dri.c | 20 +++ src/uxa/intel_driver.c | 247 +++

[Intel-gfx] [PATCH 04/12] Move intel_alloc_framebuffer to intel_memory.c

UXA and Glamor both share this function, so move it out of the UXA file. Signed-off-by: Keith Packard --- src/uxa/intel.h| 5 ++ src/uxa/intel_memory.c | 138 ++ src/uxa/intel_uxa.c| 158 - 3 fi

[Intel-gfx] [PATCH 02/12] Fix present debug output

Was using 'low_msc', which isn't defined anymore. Signed-off-by: Keith Packard --- src/uxa/intel_present.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c index 18fcbf8..5f98da8 100644 --- a/src/uxa/intel_present.c +++ b/src

[Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support

I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. I ran three different desktop environments (current Debian unstable versions): XFCE 4.10

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo

If that won't work, you could just use a timer, or tie into some other event that happens when the GPU is busy (e.g. execbuf or retire) instead of trying to tie into the display side of things. Jesse On Tue, 15 Jul 2014 06:35:20 + "Sun, Daisy" wrote: > Hi Daniel, Chris > > The concern for

[Intel-gfx] [PATCH v2] intel-gpu-tools: fix version.h creation in android

From: Tim Gore commit 743dc7997aa9f5210055896940d87c88983dcda6 breaks the build under Android because version.h is not created. This happens because the android make executes from the ANDROID_BUILD_TOP directory rather than from the directory containing the source files, so we need to differentia

[Intel-gfx] [PATCH 16/43] drm/i915/bdw: GEN-specific logical ring init

From: Oscar Mateo Logical rings do not need most of the initialization their legacy ringbuffer counterparts do: we just need the pipe control object for the render ring, enable Execlists on the hardware and a few workarounds. v2: Squash with: "drm/i915: Extract pipe control fini & make init outs

[Intel-gfx] [PATCH 13/43] drm/i915: Abstract the legacy workload submission mechanism away

From: Oscar Mateo As suggested by Daniel Vetter. The idea, in subsequent patches, is to provide an alternative to these vfuncs for the Execlists submission mechanism. v2: Splitted into two and reordered to illustrate our intentions, instead of showing it off. Also, remove the add_request vfunc a

[Intel-gfx] [PATCH 33/43] drm/i915/bdw: Help out the ctx switch interrupt handler

From: Oscar Mateo If we receive a storm of requests for the same context (see gem_storedw_loop_*) we might end up iterating over too many elements in interrupt time, looking for contexts to squash together. Instead, share the burden by giving more intelligence to the queue function. At most, the

[Intel-gfx] [PATCH 38/43] drm/i915/bdw: Display context backing obj & ringbuffer info in debugfs

From: Oscar Mateo Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_debugfs.c | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 903ed67..0980cdd 100644 --- a/dr

[Intel-gfx] [PATCH 40/43] drm/i915/bdw: Document Logical Rings, LR contexts and Execlists

From: Oscar Mateo Add theory of operation notes to intel_lrc.c and comments to externally visible functions. v2: Add notes on logical ring context creation. v3: Use kerneldoc. v4: Integrate it in the DocBook template. Signed-off-by: Thomas Daniel (v1) Signed-off-by: Oscar Mateo (v2, v3) ---

[Intel-gfx] [PATCH 43/43] drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demand

From: Oscar Mateo Same as with the context, pinning to GGTT regardless is harmful (it badly fragments the GGTT and can even exhaust it). Unfortunately, this case is also more complex than the previous one because we need to map and access the ringbuffer in several places along the execbuffer pat

[Intel-gfx] [PATCH 32/43] drm/i915/bdw: Avoid non-lite-restore preemptions

From: Oscar Mateo In the current Execlists feeding mechanism, full preemption is not supported yet: only lite-restores are allowed (this is: the GPU simply samples a new tail pointer for the context currently in execution). But we have identified an scenario in which a full preemption occurs: 1)

[Intel-gfx] [PATCH 18/43] drm/i915/bdw: New logical ring submission mechanism

From: Oscar Mateo Well, new-ish: if all this code looks familiar, that's because it's a clone of the existing submission mechanism (with some modifications here and there to adapt it to LRCs and Execlists). And why did we do this instead of reusing code, one might wonder? Well, there are some fe

[Intel-gfx] [PATCH 42/43] drm/i915/bdw: Pin the context backing objects to GGTT on-demand

From: Oscar Mateo Up until now, we have pinned every logical ring context backing object during creation, and left it pinned until destruction. This made my life easier, but it's a harmful thing to do, because we cause fragmentation of the GGTT (and, eventually, we would run out of space). This

[Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for Execlists

From: Oscar Mateo The batchbuffer that sets the render context state is submitted in a different way, and from different places. We needed to make both the render state preparation and free functions outside accesible, and namespace accordingly. This mess is so that all LR, LRC and Execlists fun

[Intel-gfx] [PATCH 20/43] drm/i915/bdw: GEN-specific logical ring emit flush

From: Oscar Mateo Same as the legacy-style ring->flush. v2: The BSD invalidate bit still exists in GEN8! Add it for the VCS rings (but still consolidate the blt and bsd ring flushes into one). This was noticed by Brad Volkin. v3: The command for BSD and for other rings is slightly different: ge

[Intel-gfx] [PATCH 24/43] drm/i915/bdw: GEN-specific logical ring emit batchbuffer start

From: Oscar Mateo Dispatch_execbuffer's evil twin. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_lrc.c| 28 drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++ 2 files changed, 30 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/d

[Intel-gfx] [PATCH 37/43] drm/i915/bdw: Display execlists info in debugfs

From: Oscar Mateo v2: Warn and return if LRCs are not enabled. v3: Grab the Execlists spinlock (noticed by Daniel Vetter). Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_debugfs.c | 73 +++ drivers/gpu/drm/i915/intel_lrc.c|6 --- drivers/gpu

[Intel-gfx] [PATCH 06/43] drm/i915/bdw: A bit more advanced LR context alloc/free

From: Oscar Mateo Now that we have the ability to allocate our own context backing objects and we have multiplexed one of them per engine inside the context structs, we can finally allocate and free them correctly. Regarding the context size, reading the register to calculate the sizes can work,

[Intel-gfx] [PATCH 36/43] drm/i915/bdw: Disable semaphores for Execlists

From: Oscar Mateo Up until recently, semaphores weren't enabled in BDW so we didn't care about them. But then Rodrigo came and enabled them: commit 521e62e49a42661a4ee0102644517dbe2f100a23 Author: Rodrigo Vivi drm/i915: Enable semaphores on BDW So now we have to explicitly disable

[Intel-gfx] [PATCH 02/43] drm/i915/bdw: New source and header file for LRs, LRCs and Execlists

From: Oscar Mateo Some legacy HW context code assumptions don't make sense for this new submission method, so we will place this stuff in a separate file. Note for reviewers: I've carefully considered the best name for this file and this was my best option (other possibilities were intel_lr_cont

[Intel-gfx] [PATCH 19/43] drm/i915/bdw: GEN-specific logical ring emit request

From: Oscar Mateo Very similar to the legacy add_request, only modified to account for logical ringbuffer. v2: Use MI_GLOBAL_GTT, as suggested by Brad Volkin. v3: Unify render and non-render in the same function, as noticed by Brad Volkin. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists

From: Oscar Mateo If we reset a ring after a hang, we have to make sure that we clear out all queued Execlists requests. v2: The ring is, at this point, already being correctly re-programmed for Execlists, and the hangcheck counters cleared. v3: Daniel suggests to drop the "if (execlists)" beca

[Intel-gfx] [PATCH 31/43] drm/i915/bdw: Handle context switch events

Handle all context status events in the context status buffer on every context switch interrupt. We only remove work from the execlist queue after a context status buffer reports that it has completed and we only attempt to schedule new contexts on interrupt when a previously submitted context comp

[Intel-gfx] [PATCH 26/43] drm/i915/bdw: Always use MMIO flips with Execlists

From: Oscar Mateo The normal flip function places things in the ring in the legacy way, so we either fix that or force MMIO flips always as we do in this patch. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_display.c |2 ++ drivers/gpu/drm/i915/intel_lrc.c |3 ++- 2 fil

[Intel-gfx] [PATCH 41/43] drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)

From: Oscar Mateo The time has come, the Walrus said, to talk of many things. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_drv.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index b7cf0ec..1

[Intel-gfx] [PATCH 23/43] drm/i915/bdw: Interrupts with logical rings

From: Oscar Mateo We need to attend context switch interrupts from all rings. Also, fixed writing IMR/IER and added HWSTAM at ring init time. Notice that, if added to irq_enable_mask, the context switch interrupts would be incorrectly masked out when the user interrupts are due to no users waiti

[Intel-gfx] [PATCH 17/43] drm/i915/bdw: GEN-specific logical ring set/get seqno

From: Oscar Mateo No mistery here: the seqno is still retrieved from the engine's HW status page (the one in the default context. For the moment, I see no reason to worry about other context's HWS page). Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_lrc.c | 20 +++

[Intel-gfx] [PATCH 39/43] drm/i915/bdw: Print context state in debugfs

From: Ben Widawsky This has turned out to be really handy in debug so far. Update: Since writing this patch, I've gotten similar code upstream for error state. I've used it quite a bit in debugfs however, and I'd like to keep it here at least until preemption is working. Signed-off-by: Ben Wida

[Intel-gfx] [PATCH 35/43] drm/i915/bdw: Make sure error capture keeps working with Execlists

From: Oscar Mateo Since the ringbuffer does not belong per engine anymore, we have to make sure that we are always recording the correct ringbuffer. TODO: This is only a small fix to keep basic error capture working, but we need to add more information for it to be useful (e.g. dump the context

[Intel-gfx] [PATCH 30/43] drm/i915/bdw: Two-stage execlist submit process

From: Michel Thierry Context switch (and execlist submission) should happen only when other contexts are not active, otherwise pre-emption occurs. To assure this, we place context switch requests in a queue and those request are later consumed when the right context switch interrupt is received

[Intel-gfx] [PATCH 29/43] drm/i915/bdw: Write the tail pointer, LRC style

From: Oscar Mateo Each logical ring context has the tail pointer in the context object, so update it before submission. v2: New namespace. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_lrc.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm

[Intel-gfx] [PATCH 25/43] drm/i915/bdw: Workload submission mechanism for Execlists

From: Oscar Mateo This is what i915_gem_do_execbuffer calls when it wants to execute some worload in an Execlists world. v2: Check arguments before doing stuff in intel_execlists_submission. Also, get rel_constants parsing right. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 22/43] drm/i915/bdw: Ring idle and stop with logical rings

From: Oscar Mateo This is a hard one, since there is no direct hardware ring to control when in Execlists. We reuse intel_ring_idle here, but it should be fine as long as i915_add_request does the ring thing. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_lrc.c | 24 +

[Intel-gfx] [PATCH 28/43] drm/i915/bdw: Implement context switching (somewhat)

From: Ben Widawsky A context switch occurs by submitting a context descriptor to the ExecList Submission Port. Given that we can now initialize a context, it's possible to begin implementing the context switch by creating the descriptor and submitting it to ELSP (actually two, since the ELSP has

[Intel-gfx] [PATCH 14/43] drm/i915/bdw: Skeleton for the new logical rings submission path

From: Oscar Mateo Execlists are indeed a brave new world with respect to workload submission to the GPU. In previous version of these series, I have tried to impact the legacy ringbuffer submission path as little as possible (mostly, passing the context around and using the correct ringbuffer wh

[Intel-gfx] [PATCH 15/43] drm/i915/bdw: Generic logical ring init and cleanup

From: Oscar Mateo Allocate and populate the default LRC for every ring, call gen-specific init/cleanup, init/fini the command parser and set the status page (now inside the LRC object). These are things all engines/rings have in common. Stopping the ring before cleanup and initializing the seqno

[Intel-gfx] [PATCH 21/43] drm/i915/bdw: Emission of requests with logical rings

From: Oscar Mateo On a previous iteration of this patch, I created an Execlists version of __i915_add_request and asbtracted it away as a vfunc. Daniel Vetter wondered then why that was needed: "with the clean split in command submission I expect every function to know wether it'll submit to an

[Intel-gfx] [PATCH 12/43] drm/i915/bdw: Don't write PDP in the legacy way when using LRCs

From: Oscar Mateo This is mostly for correctness so that we know we are running the LR context correctly (this is, the PDPs are contained inside the context object). v2: Move the check to inside the enable PPGTT function. The switch happens in two places: the legacy context switch (that we won't

[Intel-gfx] [PATCH 01/43] drm/i915: Reorder the actual workload submission so that args checking is done earlier

From: Oscar Mateo In this patch: commit 78382593e921c88371abd019aca8978db3248a8f Author: Oscar Mateo Date: Thu Jul 3 16:28:05 2014 +0100 drm/i915: Extract the actual workload submission mechanism from execbuffer So that we isolate the legacy ringbuffer submission mechanism, which be

[Intel-gfx] [PATCH 10/43] drm/i915/bdw: Deferred creation of user-created LRCs

From: Oscar Mateo The backing objects and ringbuffers for contexts created via open fd are actually empty until the user starts sending execbuffers to them. At that point, we allocate & populate them. We do this because, at create time, we really don't know which engine is going to be used with t

[Intel-gfx] [PATCH 05/43] drm/i915/bdw: Introduce one context backing object per engine

From: Oscar Mateo A context backing object only makes sense for a given engine (because it holds state data specific to that engine). In legacy ringbuffer sumission mode, the only MI_SET_CONTEXT we really perform is for the render engine, so one backing object is all we nee. With Execlists, how

[Intel-gfx] [PATCH 11/43] drm/i915/bdw: Render moot context reset and switch with Execlists

From: Oscar Mateo These two functions make no sense in an Logical Ring Context & Execlists world. v2: We got rid of lrc_enabled and centralized everything in the sanitized i915.enbale_execlists instead. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_gem_context.c |9 + 1

[Intel-gfx] [PATCH 04/43] drm/i915/bdw: Initialization for Logical Ring Contexts

From: Oscar Mateo For the moment this is just a placeholder, but it shows one of the main differences between the good ol' HW contexts and the shiny new Logical Ring Contexts: LR contexts allocate and free their own backing objects. Another difference is that the allocation is deferred (as the c

[Intel-gfx] [PATCH 03/43] drm/i915/bdw: Macro for LRCs and module option for Execlists

From: Oscar Mateo GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts". These expanded contexts enable a number of new abilities, especially "Execlists". The macro is defined to off until we have things in place to hope to work. v2: Rename "advanced contexts" to the more correct

[Intel-gfx] [PATCH 09/43] drm/i915/bdw: Populate LR contexts (somewhat)

From: Oscar Mateo For the most part, logical ring context objects are similar to hardware contexts in that the backing object is meant to be opaque. There are some exceptions where we need to poke certain offsets of the object for initialization, updating the tail pointer or updating the PDPs. F

[Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and an engine pointers to the ringbuffer

From: Oscar Mateo Any given ringbuffer is unequivocally tied to one context and one engine. By setting the appropriate pointers to them, the ringbuffer struct holds all the infromation you might need to submit a workload for processing, Execlists style. Signed-off-by: Oscar Mateo --- drivers/g

[Intel-gfx] [PATCH 07/43] drm/i915/bdw: Allocate ringbuffers for Logical Ring Contexts

From: Oscar Mateo As we have said a couple of times by now, logical ring contexts have their own ringbuffers: not only the backing pages, but the whole management struct. In a previous version of the series, this was achieved with two separate patches: drm/i915/bdw: Allocate ringbuffer backing o

[Intel-gfx] [PATCH 00/43] Execlists v5

From: Thomas Daniel For a description of this patchset, please check the previous cover letters: [1], [2], [3] and [4]. I have taken ownership of this patchset from Oscar, and this version represents his last work on the execlists patchset. The narrative below is from him. I have been given

Re: [Intel-gfx] [RFC 15/44] drm/i915: Added deferred work handler for scheduler

On 23/07/2014 19:50, Daniel Vetter wrote: On Wed, Jul 23, 2014 at 5:37 PM, John Harrison wrote: diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 0977653..fbafa68 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1075,6

Re: [Intel-gfx] [PATCH] intel-gpu-tools: fix version.h creation in android

> -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Thursday, July 24, 2014 4:27 PM > To: Gore, Tim > Cc: Intel Graphics Development > Subject: Re: [Intel-gfx] [PATCH] intel-gpu-tools: fix version.h creation in > android > > On 24 July 2014 15:40, wrote: > >

Re: [Intel-gfx] [PATCH] intel-gpu-tools: fix version.h creation in android

On 24 July 2014 15:40, wrote: > From: Tim Gore > > commit 743dc7997aa9f5210055896940d87c88983dcda6 > breaks the build under Android because version.h > is not created. This happens because the android > make executes from the ANDROID_BUILD_TOP directory > rather than from the directory containin

[Intel-gfx] [PATCH] intel-gpu-tools: fix version.h creation in android

From: Tim Gore commit 743dc7997aa9f5210055896940d87c88983dcda6 breaks the build under Android because version.h is not created. This happens because the android make executes from the ANDROID_BUILD_TOP directory rather than from the directory containing the source files, so we need Android specif

[Intel-gfx] [PATCH] drm/i915: Fix crash when failing to parse MIPI VBT

From: Rafael Barbalho This particular nasty presented itself while trying to register the intelfb device (intel_fbdev.c). During the process of registering the device the driver will disable the crtc via i9xx_crtc_disable. These will also disable the panel using the generic mipi panel functions i

Re: [Intel-gfx] [PATCH] igt_core: Inject subtest message into dmesg

On Thu, Jul 24, 2014 at 02:58:08PM +0100, Chris Wilson wrote: > On Thu, Jul 24, 2014 at 02:03:01PM +0100, Thomas Wood wrote: > > On 24 July 2014 13:36, Daniel Vetter wrote: > > > On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote: > > >> One of the side-effects we test for are kernel oop

Re: [Intel-gfx] [PATCH] igt_core: Inject subtest message into dmesg

On Thu, Jul 24, 2014 at 02:03:01PM +0100, Thomas Wood wrote: > On 24 July 2014 13:36, Daniel Vetter wrote: > > On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote: > >> One of the side-effects we test for are kernel oops and knowing the > >> guilty subtest can help speed up debugging. We

[Intel-gfx] [PATCH] intel-gpu-tools: add sys/wait.h to pm_rps.c

From: Tim Gore commit 745945546f7366a413a3a51a37f90caa3a227b1d breaks the build under Android because some of the macros used in pm_rps.c are defined in sys/wait.h which is not included. Signed-off-by: Tim Gore --- tests/pm_rps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/pm_rps

Re: [Intel-gfx] [PATCH] drm: Unlink dead file_priv from list of active files first

Hi On Thu, Jul 24, 2014 at 3:23 PM, Chris Wilson wrote: > In order to prevent external observers walking the list of open DRM > files from seeing an invalid drm_file_private in the process of being > torndown, the first operation we need to take is to unlink the > drm_file_private from that list.

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Keep spin_lock/unlock in the same block

All of the NULL tests are a bit complicated but since they are there anyway, I guess it is reasonable to take advantage of them. julia On Thu, 24 Jul 2014, Chris Wilson wrote: > Move the code around in order to acquire and release the spinlock in the > same function and in the same block. This k

[Intel-gfx] [PATCH] drm: Unlink dead file_priv from list of active files first

In order to prevent external observers walking the list of open DRM files from seeing an invalid drm_file_private in the process of being torndown, the first operation we need to take is to unlink the drm_file_private from that list. general protection fault: [#1] PREEMPT SMP

Re: [Intel-gfx] [PATCH] igt_core: Inject subtest message into dmesg

On 24 July 2014 13:36, Daniel Vetter wrote: > On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote: >> One of the side-effects we test for are kernel oops and knowing the >> guilty subtest can help speed up debugging. We can write to /dev/kmsg to >> inject messages into dmesg, so let's do

Re: [Intel-gfx] WAs in init_clock_gating?

On 24/07/2014 13:33, Daniel Vetter wrote: On Thu, Jul 24, 2014 at 11:43:11AM +0100, Siluvery, Arun wrote: On 07/07/2014 22:24, Daniel Vetter wrote: On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes wrote: I don't think it's unreasonable to use a macro that checks a global list for whether to appl

Re: [Intel-gfx] [PATCH] igt_core: Inject subtest message into dmesg

On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote: > One of the side-effects we test for are kernel oops and knowing the > guilty subtest can help speed up debugging. We can write to /dev/kmsg to > inject messages into dmesg, so let's do so before the start of every > test. > > Signed-o

Re: [Intel-gfx] WAs in init_clock_gating?

On Thu, Jul 24, 2014 at 11:43:11AM +0100, Siluvery, Arun wrote: > On 07/07/2014 22:24, Daniel Vetter wrote: > >On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes > >wrote: > >>I don't think it's unreasonable to use a macro that checks a global > >>list for whether to apply a given WA. They'll be scat

[Intel-gfx] [PATCH] drm/i915/userptr: Keep spin_lock/unlock in the same block

Move the code around in order to acquire and release the spinlock in the same function and in the same block. This keeps static analysers happy and the reader sane. Suggested-by: Julia Lawall Signed-off-by: Chris Wilson Cc: Julia Lawall --- drivers/gpu/drm/i915/i915_gem_userptr.c | 17

[Intel-gfx] [PATCH] igt_core: Inject subtest message into dmesg

One of the side-effects we test for are kernel oops and knowing the guilty subtest can help speed up debugging. We can write to /dev/kmsg to inject messages into dmesg, so let's do so before the start of every test. Signed-off-by: Chris Wilson --- lib/igt_core.c | 29

Re: [Intel-gfx] WAs in init_clock_gating?

On 07/07/2014 22:24, Daniel Vetter wrote: On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes wrote: I don't think it's unreasonable to use a macro that checks a global list for whether to apply a given WA. They'll be scattered all over, but at least it'll be easy to see: 1) whether we implement

Re: [Intel-gfx] [PATCH i-g-t 8/8] lib: add a command line option to enable debug output in tests

See my comment on patch 6. --debug returns 'd' from getopt, which can conflict with the short options for some tests, such as gem_render_copy and gem_seqn0_wrap. This problem also exists for the --run-subtest. Tim > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com]

Re: [Intel-gfx] [PATCH i-g-t 7/8] lib: always warn about unknown options

Yes, this looks sensible. > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Wednesday, July 23, 2014 11:58 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gore, Tim; daniel.vet...@ffwll.ch > Subject: [PATCH i-g-t 7/8] lib: always warn about unknown options > >

Re: [Intel-gfx] [PATCH i-g-t 6/8] tests: convert simple tests to use igt_simple_init_parse_opts

There is a problem here with the -r option in gem_seqno_wrap, as this conflicts with the --run-subtest option in common_init. This is a general issue with this method of splitting the responsibility for parsing the command line. As the common command line options defined in common_init (--run-subte

[Intel-gfx] [PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

In my review of commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 Author: Rob Clark Date: Fri May 30 11:37:03 2014 -0400 drm: add object property typ I asked for a check to make sure that we never leak an fb from the generic mode object lookup since those have completely different lifetime

Re: [Intel-gfx] [PATCH i-g-t 5/8] lib: don't ignore unknown options in multi-tests

Looks sensible. > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Wednesday, July 23, 2014 11:58 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gore, Tim; daniel.vet...@ffwll.ch > Subject: [PATCH i-g-t 5/8] lib: don't ignore unknown options in multi-tests > >

Re: [Intel-gfx] [PATCH i-g-t 4/8] lib: add igt_simple_init_parse_opts

Looks fine. > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Wednesday, July 23, 2014 11:58 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gore, Tim; daniel.vet...@ffwll.ch > Subject: [PATCH i-g-t 4/8] lib: add igt_simple_init_parse_opts > > This function al

Re: [Intel-gfx] [PATCH i-g-t 3/8] lib: move option parsing into common_init

Looks fine. > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Wednesday, July 23, 2014 11:58 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gore, Tim; daniel.vet...@ffwll.ch > Subject: [PATCH i-g-t 3/8] lib: move option parsing into common_init > > Move optio

Re: [Intel-gfx] [PATCH i-g-t 2/8] tests: remove unused getopt header includes

Looks fine to me. > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Wednesday, July 23, 2014 11:58 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gore, Tim; daniel.vet...@ffwll.ch > Subject: [PATCH i-g-t 2/8] tests: remove unused getopt header includes > > Si

Re: [Intel-gfx] [PATCH i-g-t 1/8] lib: warn when attempting to run an unknown subtest

Looks fine to me > -Original Message- > From: Thomas Wood [mailto:thomas.w...@intel.com] > Sent: Wednesday, July 23, 2014 11:58 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gore, Tim; daniel.vet...@ffwll.ch > Subject: [PATCH i-g-t 1/8] lib: warn when attempting to run an unknown > subtes

Re: [Intel-gfx] [PATCH] igt/gem_userptr_blits: Fix multi-threaded mm stress tester

On Thu, Jul 24, 2014 at 08:19:19AM +, Gore, Tim wrote: > > > -Original Message- > > From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] > > Sent: Tuesday, July 22, 2014 11:15 AM > > To: Intel-gfx@lists.freedesktop.org > > Cc: Tvrtko Ursulin; Ursulin, Tvrtko; Gore, Tim > > Subj

Re: [Intel-gfx] [PATCH] igt/gem_userptr_blits: Fix multi-threaded mm stress tester

> -Original Message- > From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] > Sent: Tuesday, July 22, 2014 11:15 AM > To: Intel-gfx@lists.freedesktop.org > Cc: Tvrtko Ursulin; Ursulin, Tvrtko; Gore, Tim > Subject: [PATCH] igt/gem_userptr_blits: Fix multi-threaded mm stress tester >

Re: [Intel-gfx] [PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

On Thu, Jul 24, 2014 at 09:54:27AM +0200, Daniel Vetter wrote: > In my review of > > commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 > Author: Rob Clark > Date: Fri May 30 11:37:03 2014 -0400 > > drm: add object property typ > > I asked for a check to make sure that we never leak an fb fr

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, This time in time! Just 32bit-pae fix from Hugh, semaphores fun from Chris and a fix for runtime pm cherry-picked from next. Paulo is still working on a fix for runtime pm when X does cursor fun when the display is off, but that one isn't ready yet. Cheers, Daniel The following change

[Intel-gfx] [PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

In my review of commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 Author: Rob Clark Date: Fri May 30 11:37:03 2014 -0400 drm: add object property typ I asked for a check to make sure that we never leak an fb from the generic mode object lookup since those have completely different lifetime

Re: [Intel-gfx] [PATCH] drm/i915: fix cursor handling when runtime suspended

On Wed, Jul 23, 2014 at 08:38:19PM -0300, Paulo Zanoni wrote: > 2014-07-23 19:41 GMT-03:00 Daniel Vetter : > > On Thu, Jul 24, 2014 at 12:35:25AM +0200, Daniel Vetter wrote: > >> On Wed, Jul 23, 2014 at 06:30:59PM -0300, Paulo Zanoni wrote: > >> > From: Paulo Zanoni > >> > > >> > If we're runtime

[Intel-gfx] [PATCH] drm: Fix race when checking for fb in the generic kms obj lookup

In my review of commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9 Author: Rob Clark Date: Fri May 30 11:37:03 2014 -0400 drm: add object property typ I asked for a check to make sure that we never leak an fb from the generic mode object lookup since those have completely different lifetime