Re: [Intel-gfx] [PATCH v5 30/46] regulator: pwm: retrieve correct voltage

On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote: > Is there any reason for calling set_machine_constraints() after > device_register() in regulator_register()? I'm not sure there's a strong one, we don't really use the class device for anything, but without doing a full audit I

Re: [Intel-gfx] i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

Hi, > > We've fixed piles of those in recent kernels, but didn't backport all the > > fixes (since usually it's a silent failure, but it can correlate with > > black screens). > > Not quite completely, it seems ... > > I have built drm-intel-nightly (f261f82359), and I'm getting this: [...]

Re: [Intel-gfx] [PATCH v5 00/46] pwm: add support for atomic update

Hi Thierry, On Wed, 30 Mar 2016 22:03:23 +0200 Boris Brezillon wrote: > Hello, > > This series adds support for atomic PWM update, or IOW, the capability > to update all the parameters of a PWM device (enabled/disabled, period, > duty and polarity) in one

Re: [Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

NAK. Try plugging in an MST display, suspending the machine, then resuming it. Hotplugging still breaks (which I've traced down to this patch) I wouldn't worry about fixing this up. I'm probably going to be sending a revert for this anyway soon along with probably some of the other patches. On

Re: [Intel-gfx] [RFC] Fixing up relocation of secure buffers?

On Mon, Apr 11, 2016 at 07:47:12PM +0100, Dave Gordon wrote: > Hi, > > background to this is that one of our validation engineers has written > a test that creates a batch that loops by jumping backwards using > MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with > whatever

Re: [Intel-gfx] Updated drm-intel-testing

Daniel Vetter composed on 2016-04-11 21:45 (UTC+0200): New -testing cycle with cool stuff:... What exactly is a "testing cycle? Last Intel Xorg driver (e.g. openSUSE 42.1 released in November: xf86-video-intel; Ubuntu 16.04, due out this month: xserver-xorg-video-intel) release was, what,

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - make modeset hw state checker atomic aware (Maarten) - close races in gpu stuck detection/seqno reading (Chris) - tons of small improvements from Chris Wilson all over the gem code - more dsi/bxt work from Ramalingam - macro polish from Joonas - guc

[Intel-gfx] [RFC] Fixing up relocation of secure buffers?

Hi, background to this is that one of our validation engineers has written a test that creates a batch that loops by jumping backwards using MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with whatever instruction sequence is being tested inside the loop. This works perfectly

[Intel-gfx] [PATCH i-g-t] ksm_pipe_color: Set legacy gamma values inside loop.

When testing multple outputs, make sure to set the gamma values before testing the output. Otherwise we're testing using the gamma values that were reset after last output was tested. Without this, the first output passes, but each output after that will fail. Signed-off-by: Bob Paauwe

Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

On Mon, 11 Apr 2016 14:43:39 +0100 Lionel Landwerlin wrote: > Color management properties are a bit of an odd use case because > they're not marked as atomic properties. Currently we're not updating > the non atomic values so the drm_crtc_state is out of sync with

[Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some much needed clean-up was done, but unfortunately part of the change broke DP MST. The real issue was setting the connector state to disconnected in the MST case, which is good, but the code then (after a goto) checks if the

[Intel-gfx] [PATCH v4] test/gem_mocs_settings: Testing MOCS register settings

The MOCS registers were added in Gen9 and define the caching policy. The registers are split into two sets. The first set controls the EDRAM policy and have a set for each engine, the second set controls the L3 policy. The two sets use the same index. The RCS registers and the L3CC registers are

[Intel-gfx] ✗ Fi.CI.BAT: failure for Minor i915_dp_mst_info output enhancements (rev4)

== Series Details == Series: Minor i915_dp_mst_info output enhancements (rev4) URL : https://patchwork.freedesktop.org/series/5346/ State : failure == Summary == CC net/ipv4/tcp_cubic.o CC net/ipv4/xfrm4_policy.o CC net/ipv6/xfrm6_input.o CC net/ipv4/xfrm4_state.o

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

On Mon, Apr 11, 2016 at 03:57:21PM +0100, Tvrtko Ursulin wrote: > > On 11/04/16 15:44, Chris Wilson wrote: > >On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote: > >> > >>On 08/04/16 12:11, Chris Wilson wrote: > >>>When called because we have run out of vmap address space, we only

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstall

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We expect vlv_display_irq_reset() to have been called prior to > vlv_display_irq_postinstall() so let's WARN if that isn't the case. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

On Mon, 11 Apr 2016, Chris Wilson wrote: On Mon, Apr 11, 2016 at 04:02:17PM +0100, Peter Antoine wrote: + for (index = 0, offset = 0; index < size; index++, offset += 4) + { + batch[offset] = MI_STORE_REGISTER_MEM_64_BIT_ADDR; + batch[offset+1] =

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace the hand rolled IMR/IER setup in > vlv_display_irq_postinstall() > with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to > avoid > consusion since we

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Clear display interrupt before enabling when turning on the power well

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > For a bit of extra paranoia make sure the display irqs are all > cleared > before we enabled them when turning on the power well. This should > really be the case

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Move vlv/chv display irq code to a more logical place

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Reshuffle the code a bit to move the vlv/chv display irq functions > away > from the main irq hooks, next to the other sub (de,gt,etc.) hooks. > > Signed-off-by: Ville

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Skip display irq setup if display irqs aren't flagged as enabled

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > During runtime PM we'll be reinitializing interrupt support from the > ground up. However since the display power well will be off at that > time, well end up with a

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix up vlv/chv display irq setup

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The vlv/chv display irq setup was a bit of mess after I ran out of steam > when working on it last. Fix it up so that we just have a _reset() and > _postinstall() hooks

[Intel-gfx] [PATCH v3 1/3] drm/edid: Add drm_edid_get_monitor_name()

In order to include monitor name information in debugfs output we needed to add a function that would extract the monitor name from the EDID, and that function needed to reside in the file where the rest of the EDID helper functions are implemented. v2: Refactor to have

[Intel-gfx] [PATCH v3 3/3] drm/i915/dp/mst: Add source port info to debugfs output

Modify the debugfs output for i915_dp_mst_info to list the source port for the DP MST topology in question. v2: rebase v3: rebase cc: Jani Nikula Signed-off-by: Jim Bride --- drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- 1 file changed, 2

[Intel-gfx] [PATCH v3 2/3] drm/dp/mst: Enhance DP MST debugfs output

Add some additional information (input vs. output port, sink associated with VC, peer device type, max number of VCs supported) and ensure that any embedded '\0' characters in a branch device's devid string are not written to debugfs. v2: Rebase + change drm_edid_get_monitor_name() call to

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Remove "VLV magic" from irq setup

On Mon, Apr 11, 2016 at 06:20:04PM +0300, Imre Deak wrote: > On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > No clue what this is supposed to achieve. I think it's been there > > since > > the very beginning,

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make GMBUS timeout message DRM_DEBUG_KMS

On Mon, Apr 11, 2016 at 09:19:40AM +0100, Chris Wilson wrote: > On Mon, Apr 11, 2016 at 10:29:29AM +0300, Ville Syrjälä wrote: > > On Mon, Mar 07, 2016 at 05:57:00PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > There's no

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Remove "VLV magic" from irq setup

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > No clue what this is supposed to achieve. I think it's been there > since > the very beginning, so presumably some kind of kludge for very early > silicon. Let's just

Re: [Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

On Mon, Apr 11, 2016 at 05:06:24PM +0200, Maarten Lankhorst wrote: > Op 11-04-16 om 16:43 schreef Ville Syrjälä: > > On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote: > >> This function is useful for gen2 intel devices which have no frame > >> counter, but need a way to determine

Re: [Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

On Mon, Apr 11, 2016 at 04:02:17PM +0100, Peter Antoine wrote: > >>+ for (index = 0, offset = 0; index < size; index++, offset += 4) > >>+ { > >>+ batch[offset] = MI_STORE_REGISTER_MEM_64_BIT_ADDR; > >>+ batch[offset+1] = reg_base + (index * sizeof(uint32_t)); > >>+

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Unduplicate CHV pre-encoder enabling phy logic

On Fri, Apr 08, 2016 at 06:31:45PM +0300, Ander Conselvan de Oliveira wrote: > The only difference between the DP and HDMI versions was the lane count. > Since lane_count is now set appropriately for HDMI too, get rid of the > duplication and move this to intel_dpio_phy.c > > Signed-off-by: Ander

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Unduplicate CHV signal level code

On Fri, Apr 08, 2016 at 06:31:42PM +0300, Ander Conselvan de Oliveira wrote: > The code for programming voltage swing and emphasis was duplicated > between DP and HDMI code. Move that to a new file, intel_dpio_phy.c. > > Signed-off-by: Ander Conselvan de Oliveira >

Re: [Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

Op 11-04-16 om 16:43 schreef Ville Syrjälä: > On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote: >> This function is useful for gen2 intel devices which have no frame >> counter, but need a way to determine the current vblank count without >> racing with the vblank interrupt

Re: [Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

On Mon, 11 Apr 2016, Chris Wilson wrote: On Mon, Apr 11, 2016 at 01:51:25PM +0100, Peter Antoine wrote: The MOCS registers were added in Gen9 and define the caching policy. The registers are split into two sets. The first set controls the EDRAM policy and have a set for each engine, the second

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

On 11/04/16 15:44, Chris Wilson wrote: On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote: On 08/04/16 12:11, Chris Wilson wrote: When called because we have run out of vmap address space, we only need to recover objects that have vmappings and not all. v2: Start using

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote: > > On 08/04/16 12:11, Chris Wilson wrote: > >When called because we have run out of vmap address space, we only need > >to recover objects that have vmappings and not all. > > > >v2: Start using is_vmalloc_addr() > > >

Re: [Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote: > This function is useful for gen2 intel devices which have no frame > counter, but need a way to determine the current vblank count without > racing with the vblank interrupt handler. > > intel_pipe_update_start checks if no

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Avoid allocating a vmap arena for a single page

On 08/04/16 12:11, Chris Wilson wrote: If we want a contiguous mapping of a single page sized object, we can forgo using vmap() and just use a regular kmap(). Note that this is only suitable if the desired pgprot_t is compatible. v2: Use is_vmalloc_addr() Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix VLV/CHV unclaimed register errors

== Series Details == Series: drm/i915: Fix VLV/CHV unclaimed register errors URL : https://patchwork.freedesktop.org/series/5531/ State : failure == Summary == Series 5531v1 drm/i915: Fix VLV/CHV unclaimed register errors http://patchwork.freedesktop.org/api/1.0/series/5531/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

On 08/04/16 12:11, Chris Wilson wrote: When called because we have run out of vmap address space, we only need to recover objects that have vmappings and not all. v2: Start using is_vmalloc_addr() Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Refactor duplicate object vmap functions

On 08/04/16 12:11, Chris Wilson wrote: We now have two implementations for vmapping a whole object, one for dma-buf and one for the ringbuffer. If we couple the mapping into the obj->pages lifetime, then we can reuse an obj->mapping for both and at the same time couple it into the shrinker.

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Late request cancellations are harmful

On Mon, Apr 11, 2016 at 02:50:17PM +0100, Tvrtko Ursulin wrote: > > On 09/04/16 10:27, Chris Wilson wrote: > >Conceptually, each request is a record of a hardware transaction - we > >build up a list of pending commands and then either commit them to > >hardware, or cancel them. However, whilst

[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

== Series Details == Series: Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv" URL : https://patchwork.freedesktop.org/series/5528/ State : failure == Summary == Series 5528v1 Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[Intel-gfx] [PATCH 08/10] drm/i915: Move vlv_init_display_clock_gating() to the display power well

From: Ville Syrjälä The registers frobbed by vlv_init_display_clock_gating() libve inside the disp2d power well, so frobbing them while the power well is down results in unclaimed register access warning (and of course the values won't stick). Let's do this setup

[Intel-gfx] [PATCH 00/10] drm/i915: Fix VLV/CHV unclaimed register errors

From: Ville Syrjälä There were two main causes for the VLV/CHV unclaimed register errors during runtime PM transitons: dipslay irq setup and vlv_init_display_clock_gating(). This series reorganizes those things so that we only do them when the disp2d power well is

[Intel-gfx] [PATCH 09/10] drm/i915: Move DPINVGTT setup to vlv_display_irq_reset()

From: Ville Syrjälä DPINVGTT lives inside the disp2d power well so we can't frob it unless we know the power well is active. Let's this stuff into vlv_display_irq_reset() which is only called at the right times so that we don't get unclaimed register access errors.

[Intel-gfx] [PATCH 05/10] drm/i915: Clear display interrupt before enabling when turning on the power well

From: Ville Syrjälä For a bit of extra paranoia make sure the display irqs are all cleared before we enabled them when turning on the power well. This should really be the case already since the power well was off which resets everything. Signed-off-by: Ville

[Intel-gfx] [PATCH 10/10] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

From: Ville Syrjälä Enable the unclaimd register detection stuff on vlv/chv since we've now fixed the known problems during suspend. This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 07/10] drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstall

From: Ville Syrjälä We expect vlv_display_irq_reset() to have been called prior to vlv_display_irq_postinstall() so let's WARN if that isn't the case. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 3 +++ 1 file

[Intel-gfx] [PATCH 06/10] drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()

From: Ville Syrjälä Replace the hand rolled IMR/IER setup in vlv_display_irq_postinstall() with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to avoid consusion since we no longer deal with IIR here. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 04/10] drm/i915: Move vlv/chv display irq code to a more logical place

From: Ville Syrjälä Reshuffle the code a bit to move the vlv/chv display irq functions away from the main irq hooks, next to the other sub (de,gt,etc.) hooks. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 98

[Intel-gfx] [PATCH 03/10] drm/i915: Skip display irq setup if display irqs aren't flagged as enabled

From: Ville Syrjälä During runtime PM we'll be reinitializing interrupt support from the ground up. However since the display power well will be off at that time, well end up with a ton of unclaimed register accesses from the display irq setup. Since we turned off

[Intel-gfx] [PATCH 02/10] drm/i915: Fix up vlv/chv display irq setup

From: Ville Syrjälä The vlv/chv display irq setup was a bit of mess after I ran out of steam when working on it last. Fix it up so that we just have a _reset() and _postinstall() hooks for the display irqs, and use those consistently. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 01/10] drm/i915: Remove "VLV magic" from irq setup

From: Ville Syrjälä No clue what this is supposed to achieve. I think it's been there since the very beginning, so presumably some kind of kludge for very early silicon. Let's just throw it out. Signed-off-by: Ville Syrjälä ---

Re: [Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

On Mon, Apr 11, 2016 at 02:37:09PM +0100, Chris Wilson wrote: > On Mon, Apr 11, 2016 at 04:31:28PM +0300, Ville Syrjälä wrote: > > On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote: > > > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. > > > > Not quite yet. I have

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Late request cancellations are harmful

On 09/04/16 10:27, Chris Wilson wrote: Conceptually, each request is a record of a hardware transaction - we build up a list of pending commands and then either commit them to hardware, or cancel them. However, whilst building up the list of pending commands, we may modify state outside of the

[Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

Color management properties are a bit of an odd use case because they're not marked as atomic properties. Currently we're not updating the non atomic values so the drm_crtc_state is out of sync with the values stored in the crtc object. v2: Update non atomic values only if commit succeeds (Bob

Re: [Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

On Mon, Apr 11, 2016 at 04:31:28PM +0300, Ville Syrjälä wrote: > On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote: > > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. > > Not quite yet. I have patches pretty much line up to fix the resulting > spew. Just got a bit

Re: [Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

On Mon, Apr 11, 2016 at 01:51:25PM +0100, Peter Antoine wrote: > The MOCS registers were added in Gen9 and define the caching policy. > The registers are split into two sets. The first set controls the > EDRAM policy and have a set for each engine, the second set controls > the L3 policy. The two

Re: [Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote: > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. Not quite yet. I have patches pretty much line up to fix the resulting spew. Just got a bit sidetracked by the CHV irq problems. > --- >

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix eDP low vswing for Broadwell

On Thu, Mar 17, 2016 at 12:23:10PM +0200, Mika Kahola wrote: > It was noticed on bug #94087 that module parameter > i915.edp_vswing=2 that should override the VBT setting > to use default voltage swing (400 mV) was not applied > for Broadwell. > > This patch provides a fix for this by checking if

Re: [Intel-gfx] [PATCH 12/16] drm/i915/bxt: Sanitize the DBUF HW state together with CDCLK

Imre Deak writes: > [ text/plain ] > When determining whether CDCLK is enabled by BIOS and so we should skip > reprogramming it, we didn't check the related DBUF power request and > state. In theory BIOS could enable one without the other so check for > this case and

Re: [Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function

>-Original Message- >From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] >Sent: Monday, April 11, 2016 6:06 PM >To: R, Durgadoss ; intel-gfx@lists.freedesktop.org >Cc: ville.syrj...@linux.intel.com >Subject: Re: [PATCHv3 1/4] drm/i915: Make finding unused

[Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86. --- drivers/gpu/drm/i915/intel_uncore.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index ac2ac07b505b..2f7fb7d169b8 100644 ---

Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

On Mon, 11 Apr 2016, Chris Wilson wrote: On Mon, Apr 11, 2016 at 01:50:16PM +0100, Peter Antoine wrote: On Fri, 8 Apr 2016, Chris Wilson wrote: + execbuf.flags = I915_EXEC_SECURE | engine_id; + + gem_execbuf(fd, ); + gem_sync(fd, handle); ^ Papering over a bug in

Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

On Mon, Apr 11, 2016 at 01:50:16PM +0100, Peter Antoine wrote: > On Fri, 8 Apr 2016, Chris Wilson wrote: > >>+ execbuf.flags = I915_EXEC_SECURE | engine_id; > >>+ > >>+ gem_execbuf(fd, ); > >>+ gem_sync(fd, handle); > > > > ^ Papering over a bug in your code. > > > >Hint: did you tell

[Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

The MOCS registers were added in Gen9 and define the caching policy. The registers are split into two sets. The first set controls the EDRAM policy and have a set for each engine, the second set controls the L3 policy. The two sets use the same index. The RCS registers and the L3CC registers are

Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

On Fri, 8 Apr 2016, Chris Wilson wrote: On Fri, Apr 08, 2016 at 05:44:13PM +0100, Peter Antoine wrote: +static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc, +uint32_t *batch, +uint32_t dst_handle, +

Re: [Intel-gfx] [PATCH 01/16] drm/i915/bxt: Reject DMC firmware versions with known bugs

Imre Deak writes: > [ text/plain ] > DMC version 1.06 has a known bug, where the firmware polls forever for a port > PLL to lock, if the PLL was disabled when entering DC5. Version 1.07 fixes > this, so make that the minimum required version on BXT. > If this would be for

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI-ping,01/10] drm/i915: Force clean compilation with -Werror

== Series Details == Series: series starting with [CI-ping,01/10] drm/i915: Force clean compilation with -Werror URL : https://patchwork.freedesktop.org/series/5518/ State : failure == Summary == Series 5518v1 Series without cover letter

Re: [Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll

On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote: > Currently, the required shared dpll is saved in the crtc_state. > Similarly, this patch saves the dpll config values also, so that > these values (through crtc_state->shared_dpll->config.hw_state) > can be used for upfront link training. > >

Re: [Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function

On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote: > Looping over the crtc list and finding an unused crtc > has other users like upfront link training. Hence move it to > a common function to re-use the logic. > > v3: > * Added kernel Doc and removed an invalid comment (Ander) > * Rebased on

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for legacy mode

On Mon, Apr 11, 2016 at 11:32:20AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id > for legacy mode > URL : https://patchwork.freedesktop.org/series/5515/ > State : failure > > == Summary == > > Series 5515v1

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for legacy mode

== Series Details == Series: series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for legacy mode URL : https://patchwork.freedesktop.org/series/5515/ State : failure == Summary == Series 5515v1 Series without cover letter

[Intel-gfx] [CI-ping 07/10] drm/i915: Store the reset counter when constructing a request

As the request is only valid during the same global reset epoch, we can record the current reset_counter when constructing the request and reuse it when waiting upon that request in future. This removes a very hairy atomic check serialised by the struct_mutex at the time of waiting and allows us

[Intel-gfx] [CI-ping 05/10] drm/i915: Simplify checking of GPU reset_counter in display pageflips

If we, when we store the reset_counter for the operation, we ensure that it is not in a wedged or in the middle of a reset, we can then assert that if any reset occurs the reset_counter must change. Later we can just compare the operation's reset epoch against the current counter to see if we need

[Intel-gfx] [CI-ping 03/10] drm/i915: Add GEM debugging Kconfig option

Currently there is a #define to enable extra BUG_ON for debugging requests and associated activities. I want to expand its use to cover all of GEM internals (so that we can saturate the code with asserts). We can add a Kconfig option to make it easier to enable - with the usual caveats of not

[Intel-gfx] [CI-ping 06/10] drm/i915: Tighten reset_counter for reset status

In the reset_counter, we use two bits to track a GPU hang and reset. The low bit is a "reset-in-progress" flag that we set to signal when we need to break waiters in order for the recovery task to grab the mutex. As soon as the recovery task has the mutex, we can clear that flag (which we do by

[Intel-gfx] [CI-ping 09/10] drm/i915: Prevent leaking of -EIO from i915_wait_request()

Reporting -EIO from i915_wait_request() has proven very troublematic over the years, with numerous hard-to-reproduce bugs cropping up in the corner case of where a reset occurs and the code wasn't expecting such an error. If the we reset the GPU or have detected a hang and wish to reset the GPU,

[Intel-gfx] [CI-ping 10/10] drm/i915: Suppress error message when GPU resets are disabled

If we do not have lowlevel support for reseting the GPU, or if the user has explicitly disabled reseting the device, the failure is expected. Since it is an expected failure, we should be using a lower priority message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just emit the

[Intel-gfx] [CI-ping 04/10] drm/i915: Hide the atomic_read(reset_counter) behind a helper

This is principally a little bit of syntatic sugar to hide the atomic_read()s throughout the code to retrieve the current reset_counter. It also provides the other utility functions to check the reset state on the already read reset_counter, so that (in later patches) we can read it once and do

[Intel-gfx] [CI-ping 02/10] drm/i915: Disentangle i915_drv.h includes

Separate out the layers of includes (linux, drm, intel, i915) so that it is a little easier to order our definitions between our multiple reentrant headers. A couple of headers needed fixes to make them more standalone (forgotten includes, forward declarations etc). Signed-off-by: Chris Wilson

[Intel-gfx] [CI-ping 01/10] drm/i915: Force clean compilation with -Werror

Our driver compiles clean (nowadays thanks to 0day) but for me, at least, it would be beneficial if the compiler threw an error rather than a warning when it found a piece of suspect code. (I use this to compile-check patch series and want to break on the first compiler error in order to fix the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: implement WaClearTdlStateAckDirtyBits (rev3)

On 22/03/16 07:32, Patchwork wrote: == Series Details == Series: drm/i915: implement WaClearTdlStateAckDirtyBits (rev3) URL : https://patchwork.freedesktop.org/series/4282/ State : warning == Summary == Series 4282v3 drm/i915: implement WaClearTdlStateAckDirtyBits

Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

Op 11-04-16 om 12:37 schreef Lionel Landwerlin: > Color management properties are a bit of an odd use case because > they're not marked as atomic properties. Currently we're not updating > the non atomic values so the drm_crtc_state is out of sync with the > values stored in the crtc object. > >

[Intel-gfx] [for-CI 3/5] drm/i915: Reload PD tables after semaphore wait on gen8

When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] [for-CI 5/5] drm/i915: Enable legacy/semaphores for CI

--- drivers/gpu/drm/i915/intel_lrc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index f209ecfdcb5c..53b0ffed2501 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -259,10 +259,6

[Intel-gfx] [for-CI 1/5] drm/i915: Fix gen8 semaphores id for legacy mode

With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris Wilson

[Intel-gfx] [for-CI 4/5] drm/i915: Enable semaphores for legacy submission on gen8

We have sufficient evidence from igt to support that semaphores are in a working state. Enabling semaphores now for legacy provides a better comparison of execlists against legacy ring submission. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 4

[Intel-gfx] [for-CI 2/5] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--

[Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

Color management properties are a bit of an odd use case because they're not marked as atomic properties. Currently we're not updating the non atomic values so the drm_crtc_state is out of sync with the values stored in the crtc object. v2: Update non atomic values only if commit succeeds (Bob

Re: [Intel-gfx] [RFC 0/4] Eliminating the execlist retired request queue

On Mon, Apr 11, 2016 at 10:19:29AM +0100, Tvrtko Ursulin wrote: > > On 09/04/16 09:03, Chris Wilson wrote: > >On Fri, Apr 08, 2016 at 02:54:54PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Retired request queue coupled with retired work handler is a

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit (rev2)

On to, 2016-03-17 at 11:05 -0700, dw kim wrote: > On Thu, Mar 17, 2016 at 01:03:36PM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit > > (rev2) > > URL   : https://patchwork.freedesktop.org/series/4491/ > > State : failure >

Re: [Intel-gfx] [PATCH v4] drm/i915: implement WaClearTdlStateAckDirtyBits

On 21/03/2016 14:37, tim.g...@intel.com wrote: From: Tim Gore This is to fix a GPU hang seen with mid thread pre-emption and pooled EUs. v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID v3. And use correct type for register addresses Signed-off-by: Tim Gore

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

On ke, 2016-03-16 at 18:06 -0700, Dongwon Kim wrote: > For BXT, description of polarities of PORT_PLL_REF_SEL > has been reversed for newer Gen9LP steppings according to the > recent update in Bspec. This bit now should be set for > "Non-SSC" mode for all Gen9LP starting from B0 stepping. > > v2:

Re: [Intel-gfx] [RFC] Prefer INTEL_INFO(dev_priv) to INTEL_INFO(dev)

On Mon, 11 Apr 2016, Dave Gordon wrote: > For this reason, I'd like to recommend that anyone doing this sort of > bulk transformation with Cocci or awk or just sed should /always/ > include the transformation script to help those with patches in flight. I think that's

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Restore GMBUS operation after a failed bit-banging fallback

On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > When the GMBUS based i2c transfer times out, we try to fall back to > bit-banging and retry the operation that way. However if the bit-banging > attempt also fails, we should

[Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

This function is useful for gen2 intel devices which have no frame counter, but need a way to determine the current vblank count without racing with the vblank interrupt handler. intel_pipe_update_start checks if no vblank interrupt will occur during vblank evasion, but cannot check whether the

Re: [Intel-gfx] [RFC 4/4] drm/i915: Stop tracking execlists retired requests

On Mon, Apr 11, 2016 at 10:10:56AM +0100, Tvrtko Ursulin wrote: > > On 08/04/16 15:57, Chris Wilson wrote: > >On Fri, Apr 08, 2016 at 02:54:58PM +0100, Tvrtko Ursulin wrote: > >>@@ -615,11 +613,6 @@ static void execlists_context_queue(struct > >>drm_i915_gem_request *request) > >>struct

Re: [Intel-gfx] [RFC] Prefer INTEL_INFO(dev_priv) to INTEL_INFO(dev)

On 08/04/16 07:09, Joonas Lahtinen wrote: On to, 2016-04-07 at 18:57 +0100, Dave Gordon wrote: Where we have a suitable dev_priv pointer, we can use that rather than 'dev' for accessing INTEL_INFO(). This removes one level of memory reference, decreasing code size a little and possibly making

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Protect force_bit with gmbus_mutex

On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Extend the protection of gmbus_mutex around the force_bit > RMW in intel_gmbus_force_bit(), in case someone gets the > idea of calling it from a separate thread while there's > other

  1   2   >