Re: [Intel-gfx] [PATCH 2/2 v2] drm/i915: mark GEM objects dirty after overwriting their contents

On Thu, Dec 10, 2015 at 02:52:57PM +, Chris Wilson wrote: > On Thu, Dec 10, 2015 at 03:06:55PM +0100, Daniel Vetter wrote: > > On Wed, Dec 09, 2015 at 03:52:52PM +, Dave Gordon wrote: > > > In a few places, we fill a GEM object with data, or overwrite some > > > portion of its contents

Re: [Intel-gfx] [PATCH 1/2 v2] drm/i915: mark GEM object pages dirty when mapped & written by the CPU

On Thu, Dec 10, 2015 at 09:04:23PM +, Chris Wilson wrote: > On Thu, Dec 10, 2015 at 05:24:42PM +, Dave Gordon wrote: > > On 10/12/15 13:29, Chris Wilson wrote: > > >On Wed, Dec 09, 2015 at 03:52:51PM +, Dave Gordon wrote: > > >>In various places, a single page of a (regular) GEM object

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Instrument PSR parameter for possible quirks with link standby.

On Thu, Dec 10, 2015 at 08:28:23AM -0800, Rodrigo Vivi wrote: > Link standby support has been deprecated with 'commit 89251b177 > ("drm/i915: PSR: deprecate link_standby support for core platforms.")' > > The reason for that is that main link in full off offers more power > savings and some

Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote: > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote: > > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote: > > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote: > > > > On Thursday, December 10, 2015 10:36:37

Re: [Intel-gfx] [PATCH 13/13] drm/i915: Cache last IRQ seqno to reduce IRQ overhead

On Fri, Dec 11, 2015 at 03:35:54PM +, John Harrison wrote: > On 11/12/2015 14:55, Chris Wilson wrote: > >On Fri, Dec 11, 2015 at 01:12:01PM +, john.c.harri...@intel.com wrote: > >>From: John Harrison > >> > >>The notify function can be called many times without

[Intel-gfx] [PATCH i-g-t v2] gem_flink_race/prime_self_import: Improve test reliability

gem_flink_race and prime_self_import have subtests which read the number of open gem objects from debugfs to determine if objects have leaked during the test. However the test can fail sporadically if the number of gem objects changes due to other process activity. This patch introduces a change

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Interrupt driven fences

Reply moved from earlier patch set which has now been superceeded by this set... On 11/12/2015 12:17, Tvrtko Ursulin wrote: Hi, Some random comments, mostly from the point of view of solving the thundering herd problem. On 23/11/15 11:34, john.c.harri...@intel.com wrote: From: John

Re: [Intel-gfx] [PATCH 11/13] android/sync: Fix reversed sense of signaled fence

On 11/12/15 13:11, john.c.harri...@intel.com wrote: From: Peter Lawthers In the 3.14 kernel, a signaled fence was indicated by the status field == 1. In 4.x, a status == 0 indicates signaled, status < 0 indicates error, and status > 0 indicates active. This patch

Re: [Intel-gfx] [PATCH 09/13] drm/i915: Interrupt driven fences

On 11/12/15 15:30, John Harrison wrote: Reply moved from earlier patch set which has now been superceeded by this set... On 11/12/2015 12:17, Tvrtko Ursulin wrote: Hi, Some random comments, mostly from the point of view of solving the thundering herd problem. On 23/11/15 11:34,

Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote: > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote: > > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote: > > > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote: > > > > On Thursday, December 10, 2015 11:20:40 PM

Re: [Intel-gfx] [PATCH] drm/i915: Instrument PSR parameter for possible quirks with link standby.

On Fri, 2015-12-11 at 17:55 -0200, Paulo Zanoni wrote: > 2015-12-11 6:49 GMT-02:00 Rodrigo Vivi : > > Link standby support has been deprecated with 'commit 89251b177 > > ("drm/i915: PSR: deprecate link_standby support for core > > platforms.")' > > > > The reason for that

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: Fix compiler warning on 32bit systems

On Thu, Dec 10, 2015 at 04:43:29PM +, Tvrtko Ursulin wrote: > > Hi, > > On 10/12/15 14:58, Mika Kuoppala wrote: > >We get build error as we try to cast from ptr to integer > >of different size on 32 bit platforms. Use unsigned long > >as the cast, it will work with both 32 and 64 bit >

Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

On Friday, December 11, 2015 04:59:45 PM Ulf Hansson wrote: > On 11 December 2015 at 16:13, Rafael J. Wysocki wrote: > > On Friday, December 11, 2015 01:03:50 PM Ulf Hansson wrote: > >> [...] > >> > >> >> > > >> >> > Which basically means you can call pm_runtime_resume() just

[Intel-gfx] [Regression report] Weekly regression report WW50

WW50 Regression report. Last week regressions +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 93263 |

[Intel-gfx] [PATCH] intel: merge latest i915_drm.h

Pick up context flags, softpin, etc. Signed-off-by: Jesse Barnes --- include/drm/i915_drm.h | 57 ++ 1 file changed, 48 insertions(+), 9 deletions(-) diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h index

Re: [Intel-gfx] [PATCH 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl

On Wed, 25 Nov 2015 18:07:59 +0100 Daniel Vetter wrote: > Unfortunately the entire improved docbook project died at KS in a > massive bikeshed. So we need to carry this around in drm private trees > forever :( I don't think that's an entirely helpful way to look at

[Intel-gfx] [PATCH v2 3/3] drm/i915: Clean up GPU hang message

Remove some redundant kernel messages as we deduce a hung GPU and capture the error state. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git

[Intel-gfx] [PATCH v2 1/3] drm/i915: Record the ringbuffer associated with the request

The request tells us where to read the ringbuf from, so use that information to simplify the error capture. If no request was active at the time of the hang, the ring is idle and there is no information inside the ring pertaining to the hang. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 2/3] drm/i915: Allow userspace to request no-error-capture upon GPU hangs

igt likes to inject GPU hangs into its command streams. However, as we expect these hangs, we don't actually want them recorded in the dmesg output or stored in the i915_error_state (usually). To accomodate this allow userspace to set a flag on the context that any hang emanating from that context

Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

On Saturday, December 12, 2015 12:21:43 AM Rafael J. Wysocki wrote: > On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote: > > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote: > > > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote: > > > > On to, 2015-12-10 at 23:14 +0100,

[Intel-gfx] [PATCH 2/4] drm/i915: Add PSR main link standby support back

Link standby support has been deprecated with 'commit 89251b177 ("drm/i915: PSR: deprecate link_standby support for core platforms.")' The reason for that is that main link in full off offers more power savings and on HSW and BDW implementations on source side had known bugs with link standby.

[Intel-gfx] [PATCH 3/4] drm/i915: Instrument PSR parameter for possible quirks with link standby.

Unfortunately we don't know all panels and platforms out there and we found internal prototypes without VBT proper set but where only link in standby worked well. So, before enable PSR by default let's instrument the PSR parameter in a way that we can identify different panels out there that

[Intel-gfx] [PATCH 1/4] drm/i915: PSR Fix standby logic for PSR on non DDI-A for certain platforms.

Current platforms that support PSR on other port than A only support link standby mode. The logic here was wrong since 'commit 89251b177b ("drm/i915: PSR: deprecate link_standby support for core platforms.") Cc: Paulo Zanoni Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 4/4] drm/i915: Enable PSR by default.

With a reliable frontbuffer tracking and all instability corner cases solved let's re-enabled PSR by default on all supported platforms. In case a new issue is found and PSR is the main suspect, please check if i915.enable_psr=0 really makes your problem go away. If this is the case PSR is the

Re: [Intel-gfx] [PATCH v2] PM / Runtime: Introduce pm_runtime_get_noidle

On Saturday, December 12, 2015 12:41:06 AM Rafael J. Wysocki wrote: > On Saturday, December 12, 2015 12:21:43 AM Rafael J. Wysocki wrote: > > On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote: > > > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote: > > > > On Friday, December 11,

[Intel-gfx] [PATCH v2] drm/i915: Fix context/engine cleanup order

Swap the order of context & engine cleanup, so that it is now contexts, then engines. This allows the context clean up code to do things like confirm that ring->dev->struct_mutex is locked without a NULL pointer dereference. This came about as a result of the 'intel_ring_initialized() must be

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Add sync framework support to execbuff IOCTL

On 11/12/15 13:12, john.c.harri...@intel.com wrote: From: John Harrison Various projects desire a mechanism for managing dependencies between work items asynchronously. This can also include work items across complete different and independent systems. For example,

Re: [Intel-gfx] [PATCH] tests/kms_color:Color IGT

On Fri, 2015-12-11 at 16:01 +0530, Dhanya Pillai wrote: > From: Dhanya > > This patch will verify color correction capability of a display > driver. > Gamma/CSC/De-gamma for SKL/BXT supported. > > Signed-off-by: Dhanya > --- >  tests/.gitignore   

Re: [Intel-gfx] [PATCH 13/13] drm/i915: Cache last IRQ seqno to reduce IRQ overhead

On 11/12/2015 14:55, Chris Wilson wrote: On Fri, Dec 11, 2015 at 01:12:01PM +, john.c.harri...@intel.com wrote: From: John Harrison The notify function can be called many times without the seqno changing. A large number of duplicates are to prevent races due to

Re: [Intel-gfx] [MIPI SEQ PARSING v3 01/13] drm/i915: Adding the parsing logic for the i2c element

On Tue, 2015-12-01 at 04:17 +0530, Deepak M wrote: > From: vkorjani > > New sequence element for i2c is been added in the > mipi sequence block of the VBT. This patch parses > and executes the i2c sequence. > > v2: Add i2c_put_adapter call(Jani), rebase > v3: corrected

[Intel-gfx] [PATCH v4 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using

Re: [Intel-gfx] [MIPI SEQ PARSING v3 02/13] drm/i915: Updating asle structure with new fields

On Tue, 2015-12-01 at 04:17 +0530, Deepak M wrote: > v3: rebase > > Cc: Jani Nikula Tested-by: Mika Kahola > Signed-off-by: Deepak M > --- > drivers/gpu/drm/i915/intel_opregion.c | 4 +++- > 1 file changed, 3 insertions(+), 1

Re: [Intel-gfx] [MIPI SEQ PARSING v3 03/13] drm/i915: Add Intel opregion mailbox 5 structure

On Tue, 2015-12-01 at 04:17 +0530, Deepak M wrote: > Mailbox 5 is BIOS to Driver Notification mailbox is intended > to support BIOS to Driver event notification or data storage > for BIOS to Driver data synchronization purpose. Mailbox 5 is > the extension of mailbox 3. > > Cc: Jani Nikula

Re: [Intel-gfx] [MIPI SEQ PARSING v3 05/13] drm/i915: Add debug entry to get the opregion VBT blob

On Tue, 2015-12-01 at 04:17 +0530, Deepak M wrote: > Currently there is a entry to get the complete opregion > dump, this patch adds entry to get the VBT alone from > the opregion. > > Adding this entry helps developer to get the VBT easily, > instead of following the old way where we get the

Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.

On 12/4/2015 8:52 PM, Imre Deak wrote: On to, 2015-12-03 at 16:43 -0800, Bob Paauwe wrote: On Tue, 1 Dec 2015 19:43:05 +0200 Imre Deak wrote: On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote: On Tue, 1 Dec 2015 15:56:55 +0200 Imre Deak wrote:

[Intel-gfx] [PATCH 2/7] drm/i915/dp: Reuse shared DPLL if it exists already

Do not call intel_get_shared_dpll() if there exists a valid shared DPLL already. Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_ddi.c | 70 drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_drv.h

[Intel-gfx] [PATCH 6/7] drm/i915: Make finding unused crtc as a generic function

Looping over the crtc list and finding an unused crtc has users other than load_detect(). Hence move it to a common function so that we can re-use the logic. Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_display.c | 37 ++--

[Intel-gfx] [PATCH 1/7] drm/i915/dp: Reuse encoder if it is already available

We do not need to loop through crtc_state to get the encoder if we already have a valid one available. Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_ddi.c | 11 --- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_drv.h

[Intel-gfx] [PATCH 5/7] drm/i915/dp: Add methods to update link train params

Retrying with reduced lanes/bw and updating the final available lanes/bw to DPCD is needed for upfront link train logic. Hence, this patch adds these methods and exports them so that these can be called from other files like ddi.c/display.c. Signed-off-by: Durgadoss R ---

[Intel-gfx] [PATCH 0/7] Add USB typeC based DP support for BXT platform

This patch series adds upfront link training support to enable USB type C based DP on BXT platform. To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable.

[Intel-gfx] [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel can support more lanes. To address these

Re: [Intel-gfx] [PATCH] drm/i915: Instrument PSR parameter for possible quirks with link standby.

2015-12-11 6:49 GMT-02:00 Rodrigo Vivi : > Link standby support has been deprecated with 'commit 89251b177 > ("drm/i915: PSR: deprecate link_standby support for core platforms.")' > > The reason for that is that main link in full off offers more power > savings and some

[Intel-gfx] [PATCH] drm/i915: Enable PSR by default.

With a reliable frontbuffer tracking and all instability corner cases solved let's re-enabled PSR by default on all supported platforms. In case a new issue is found and PSR is the main suspect, please check if i915.enable_psr=0 really makes your problem go away. If this is the case PSR is the

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Don't leak connector state on SDVO init failure

On Thu, Dec 10, 2015 at 05:57:57PM -0800, Matt Roper wrote: > On Thu, Dec 10, 2015 at 03:14:38PM +0100, Daniel Vetter wrote: > > On Tue, Dec 08, 2015 at 02:48:51PM -0800, Matt Roper wrote: > > > In all of our various SDVO setup functions, we allocate an SDVO > > > connector (along with an

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Support for pread/pwrite from/to non shmem backed objects

On Wed, Dec 09, 2015 at 07:39:56PM +, Dave Gordon wrote: > On 09/12/15 16:15, Tvrtko Ursulin wrote: > > > >Hi, > > > >On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: > >>From: Ankitprasad Sharma > >> > >>This patch adds support for extending the

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Support for creating Stolen memory backed objects

On Fri, Dec 11, 2015 at 12:49:37PM +, Dave Gordon wrote: > On 11/12/15 12:19, Tvrtko Ursulin wrote: > > > >On 11/12/15 11:22, Ankitprasad Sharma wrote: > >>On Wed, 2015-12-09 at 14:06 +, Tvrtko Ursulin wrote: > >>>Hi, > >>> > >>>On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote: >

Re: [Intel-gfx] [PATCH 2/4 v3] drm/i915: mark a newly-created GEM object dirty when filled with data

On Thu, Dec 10, 2015 at 09:06:25PM +, Chris Wilson wrote: > On Thu, Dec 10, 2015 at 06:51:24PM +, Dave Gordon wrote: > > When creating a new (pageable) GEM object and filling it with data, we > > must mark it as 'dirty', i.e. backing store is out-of-date w.r.t. the > > newly-written

Re: [Intel-gfx] [PATCH 1/2 v2] drm/i915: mark GEM object pages dirty when mapped & written by the CPU

On Fri, Dec 11, 2015 at 06:08:10PM +0100, Daniel Vetter wrote: > Hm, I think if you force a fault on relocs and then shrink everything > really hard before actually managing to submit the batch you could provoke > this into a proper bug. one-in-a-billion perhaps ;-) Hmm, you would need to force

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Explicitly use ddi bug trans entry 9 for hdmi

On Thu, Dec 10, 2015 at 04:41:54PM +0200, Ville Syrjälä wrote: > On Thu, Dec 10, 2015 at 02:48:48PM +0100, Daniel Vetter wrote: > > On Tue, Dec 08, 2015 at 07:59:46PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > When the

Re: [Intel-gfx] [PATCH v3 06/14] drm: Add plane->name and use it in debug prints

On Tue, Dec 08, 2015 at 06:41:54PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Show a sensible name for the plane in debug mesages. The driver > may supply its own name, otherwise the core genrates the name > ("plane-0", "plane-1" etc.). >

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Migrate stolen objects before hibernation

On 11/12/15 05:16, Ankitprasad Sharma wrote: On Thu, 2015-12-10 at 14:15 +, Tvrtko Ursulin wrote: On 10/12/15 13:17, Ankitprasad Sharma wrote: On Thu, 2015-12-10 at 09:43 +, Tvrtko Ursulin wrote: Hi, Two more comments below: On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:

[Intel-gfx] [PATCH 13/13] drm/i915: Cache last IRQ seqno to reduce IRQ overhead

From: John Harrison The notify function can be called many times without the seqno changing. A large number of duplicates are to prevent races due to the requirement of not enabling interrupts until requested. However, when interrupts are enabled the IRQ handle can be

[Intel-gfx] [PATCH 03/13] staging/android/sync: Move sync framework out of staging

From: John Harrison The sync framework is now used by the i915 driver. Therefore it can be moved out of staging and into the regular tree. Also, the public interfaces can actually be made public and exported. v3: New patch for series. Signed-off-by: John Harrison

[Intel-gfx] [PATCH 12/13] drm/i915: Add sync framework support to execbuff IOCTL

From: John Harrison Various projects desire a mechanism for managing dependencies between work items asynchronously. This can also include work items across complete different and independent systems. For example, an application wants to retreive a frame from a video

[Intel-gfx] [PATCH v3] drm/i915: Avoid writing relocs with addresses in non-canonical form

According to bspec, some parts of HW require the addresses to be in a canonical form, where bits [63:48] == [47]. Let's convert addresses to canonical form prior to relocating and return converted offsets to userspace. We also need to make sure that userspace is using addresses in canonical form

[Intel-gfx] [RFC 24/38] drm/i915/sched: set request 'head' on at start of ring submission

From: Dave Gordon With the scheduler, request allocation can happen long before the ring is filled in, and in a different order. So for that case, we update the request head at the start of _final (the initialisation on allocation is stull useful for the

Re: [Intel-gfx] [PATCH 1/3] drm/i915: PSR also doesn't have link_entry_time on SKL.

On Fri, 2015-12-11 at 17:09 -0200, Paulo Zanoni wrote: > 2015-12-10 14:28 GMT-02:00 Rodrigo Vivi : > > This bit is also reserved on Skylake. Actually the only > > platform that supports this is Haswell, so let's fix > > this logic and apply this link entry time only for the

Re: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug live status checking

On Fri, Dec 11, 2015 at 03:12:05PM +0800, Gary Wang wrote: > The total delay of HDMI hotplug detecting with 30ms should have > been split into a resolution of 3 retries of 10ms each, for the worst > cases. But it still suffered from only waiting 10ms at most in > intel_hdmi_detect(). This patch

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix context/engine cleanup order

On Fri, Dec 11, 2015 at 05:26:19PM +0100, Daniel Vetter wrote: > On Fri, Dec 11, 2015 at 02:59:09PM +, Nick Hoath wrote: > > Swap the order of context & engine cleanup, so that it is now > > contexts, then engines. > > This allows the context clean up code to do things like confirm > > that

Re: [Intel-gfx] [PATCH i-g-t v2] gem_flink_race/prime_self_import: Improve test reliability

On Fri, Dec 11, 2015 at 03:18:30PM +, Derek Morton wrote: > gem_flink_race and prime_self_import have subtests which read the > number of open gem objects from debugfs to determine if objects have > leaked during the test. However the test can fail sporadically if > the number of gem objects

Re: [Intel-gfx] [PATCH] drm/i915: Add background commentary to "waitboosting"

On Thu, Dec 10, 2015 at 10:37:36AM +, Chris Wilson wrote: > Describe the intent of boosting the GPU frequency to maximum before > waiting on the GPU. > > RPS waitboosting was introduced with > > commit b29c19b645287f7062e17d70fa4e9781a01a5d88 > Author: Chris Wilson

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

Hi Dave, drm-intel-next-2015-12-04-1: This is the "fix igt basic test set issues" edition. - more PSR fixes from Rodrigo, getting closer - tons of fifo underrun fixes from Ville - runtime pm fixes from Imre, Daniel Stone - fix SDE interrupt handling properly (Jani Nikula) - hsw/bdw fdi modeset

Re: [Intel-gfx] [PATCH] drm/i915: Correct max delay for HDMI hotplug live status checking

On Fri, Dec 11, 2015 at 07:10:35AM +, Wang, Gary C wrote: > I will upload new version of patch for review. Thanks! > > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Wang, Gary C > Sent: Friday, December 11, 2015 2:23 PM > To:

[Intel-gfx] [PATCH] drm/i915: mdelay(10) considered harmful

I missed this myself when reviewing commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpy cycles spinning. Cc:

Re: [Intel-gfx] [PATCH] tests/kms_color:Color IGT

On Fri, Dec 11, 2015 at 03:35:36PM +, Rob Bradford wrote: > On Fri, 2015-12-11 at 16:01 +0530, Dhanya Pillai wrote: > > + /*Enable red planes and apply unit gamma*/ > > + fb_color.red = 1; > > + fb_color.green =0; > > + fb_color.blue = 0; > > + unit_gamma = 0; /*0 -> white 1->black*/

Re: [Intel-gfx] [PATCH] drm/i915: Allow objects to go back above 4GB in the address range

On Fri, Dec 11, 2015 at 02:49:52PM +, Chris Wilson wrote: > On Fri, Dec 11, 2015 at 02:34:13PM +, Michel Thierry wrote: > > We detected if objects should be moved to the lower parts when 48-bit > > support flag was not set, but not the other way around. > > > > This handles the case in

Re: [Intel-gfx] [PATCH 1/3] drm/i915: PSR also doesn't have link_entry_time on SKL.

2015-12-10 14:28 GMT-02:00 Rodrigo Vivi : > This bit is also reserved on Skylake. Actually the only > platform that supports this is Haswell, so let's fix > this logic and apply this link entry time only for the > platform that supports it, i.e. Haswell. > > This also

Re: [Intel-gfx] [MIPI SEQ PARSING v3 04/13] drm/i915: Do opregion VBT validation during opregion setup

On Tue, 2015-12-01 at 04:17 +0530, Deepak M wrote: > Calling the validate_vbt before assiging the opregion vbt blob. > Size of the VBT blob cant be more than 6KB when VBT is present > in mailbox 4. > > Cc: Jani Nikula Tested-by: Mika Kahola >

Re: [Intel-gfx] [MIPI SEQ PARSING v3 06/13] drm/i915: Parsing VBT if size of VBT exceeds 6KB

When testing this patch on my BXT-M I received this error message Hardware name: Intel Corp. Broxton M/RVP, BIOS BXTM_IFWI_X64_R_2015_49_2_03 11/25/2015 [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at drivers/iommu/dmar.c:829

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Prevent leaking of -EIO from i915_wait_request()

On Thu, Dec 03, 2015 at 10:14:54AM +0100, Daniel Vetter wrote: > On Tue, Dec 01, 2015 at 11:05:35AM +, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 4447e73b54db..73c61b94f7fd 100644 > > ---

Re: [Intel-gfx] [PATCH] drm/i915: mdelay(10) considered harmful

On Fri, Dec 11, 2015 at 07:44:15PM +0100, Daniel Vetter wrote: > I missed this myself when reviewing > > commit 237ed86c693d8a8e4db476976aeb30df4deac74b > Author: Sonika Jindal > Date: Tue Sep 15 09:44:20 2015 +0530 > > drm/i915: Check live status before reading

Re: [Intel-gfx] [PATCH] drm/i915: Add background commentary to "waitboosting"

On Fri, Dec 11, 2015 at 07:24:29PM +0100, Daniel Vetter wrote: > On Thu, Dec 10, 2015 at 10:37:36AM +, Chris Wilson wrote: > > Describe the intent of boosting the GPU frequency to maximum before > > waiting on the GPU. > > > > RPS waitboosting was introduced with > > > > commit

<    1   2