On Thu, Apr 21, 2016 at 09:48:36AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > static bool
> > -needs_pd_load_pre(struct intel_engine_cs *engine, struct intel_context *to)
> > +needs_pd_load_pre(struct i915_hw_ppgtt *ppgtt,
> > + struct int
On 20 April 2016 at 20:16, wrote:
> From: Ville Syrjälä
>
> create_bo_for_fb() expects the drm format as a parameter since
> commit 8a1a38661f56 ("lib: Add igt_create_bo_with_dimensions")
> but not all callers were updated. Fix that up.
>
> Cc: Tomeu Vizoso
> Fixes: 8a1a38661f56 ("lib: Add igt_
On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> Instead of allocating a new request when allocating a context, use the
> request that initiated the allocation to emit the context
> initialisation. This serves two purposes, it makes the initialisation
> atomic with first use (simplifying sch
== Series Details ==
Series: drm/i915: Make RPS EI/thresholds multiple of 25 on SNB
URL : https://patchwork.freedesktop.org/series/5987/
State : success
== Summary ==
Series 5987v1 drm/i915: Make RPS EI/thresholds multiple of 25 on SNB
http://patchwork.freedesktop.org/api/1.0/series/5987/revis
On Thu, Apr 21, 2016 at 12:33:40PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> There are certain registers, which captures the time elapsed in the
> in current Up/Down EI, for how long GT has been Idle/Busy/Avg in the
> current Up/Down EI and also in the previous Up/Down EI.
> These
From: Akash Goel
As a part of WaGsvDisableTurbo, Driver makes an early exit from the
Gen9 Turbo enabling function, so doesn't program the Turbo Control register.
But BIOS could leave the Hw Turbo as enabled, so need to explicitly clear
out the Control register just to avoid inconsitency with debu
From: Akash Goel
There are certain registers, which captures the time elapsed in the
in current Up/Down EI, for how long GT has been Idle/Busy/Avg in the
current Up/Down EI and also in the previous Up/Down EI.
These register values are reported by the i915_frequency_info debugfs
interface. The Dr
On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> The code to switch_mm() is already handled by i915_switch_context(), the
> only difference required to setup the aliasing ppgtt is that we need to
> emit te switch_mm() on the first context, i.e. when transitioning from
> engine->last_context
The exact same code was used by HDMI and DP encoders, so move it to
intel_dpio_phy.c.
v2: Fix typo in the commit message. (Jim Bride)
Cc: Jim Bride
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp
The phy code in vlv_pre_enable_dp() and vlv_hdmi_pre_enable() is
exectly the same, so extract it to intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 24 +
The function chv_data_lane_soft_reset() was duplicated in DP and HDMI
code. Move it to intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 44 -
The code used by the DP and HDMI paths was very similar, so make them
share it. Note that this removes the write to signal level registers
from the HDMI pre pll enable path, but that's OK since those are set
in vlv_hdmi_pre_enable() function.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-b
The logic for setting signal levels is used for both HDMI and DP with
small variations. But it is similar enough to put behind a function
called from the encoders.
v2: Remove unrelated MST changes due to rebase fumble. (Jim Bride)
Fix typo in the commit message. (Jim Bride)
v3: Really fix the
This moves the last phy specific code from the encoders to the phy
specific file.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dpio_phy.c | 15 +++
drivers/gpu/drm/i915/intel_hdmi.c
Set the lane count for HDMI to 4. This will make it easier to
unduplicate CHV phy code.
v2: Set lane_count in *_get_config() to please state checker. (0day)
v3: Set lane_count for DDI in DVI mode too. (CI)
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i
I messed up the in-reply-to field while sending a couple of updated
patches, so patchwork didn't catch the new revision. Sending again so
these get another run of CI.
Ander
Ander Conselvan de Oliveira (10):
drm/i915: Set crtc_state->lane_count for HDMI
drm/i915: Unduplicate CHV signal level c
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
v2: Don't move comments about 2nd common lane staying alive. (Ville)
Signed-off-by: Ander Conselvan de Olive
The same logic is used for DP and HDMI so move it to intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 83 +--
drivers/gpu/drm/i915/intel_
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.
v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville)
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Jim Bride
---
drivers/gpu/drm/i915/Make
This patch forces panel to use fail safe mode when it is detected
that edid is corrupt
For now this is performed only when automated test request is
received. This is because DRM's edid parser recovers from
basic corruption in edid resulting in normal functioning.
This can be modified to be used
On Wednesday 20 April 2016 06:56 PM, Daniel Vetter wrote:
On Tue, Apr 19, 2016 at 01:48:14PM +0530, Ramalingam C wrote:
In BXT DSI there is no regs programmed with few horizontal timings
in Pixels but txbyteclkhs.. So retrieval process adds some
ROUND_UP ERRORS in the process of PIXELS<==>txbyt
Hi Ville,
Please ignore my last email.
I think I finally got it what you exactly suggested.
Please check another patch sent by me:
drm/i915: Fake HDMI live status
There are two versions of this patch:
v1: fake live_status = true for all platforms.
v2: fake live_status = t
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
While testing certain (monitor + cable) combinations with
various intel platforms, it seems that live status register
doesn't work reliably on some older devices. So limit the
live_status check fo
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
While testing certain (monitor + cable) combinations with
various intel platforms, it seems that live status register
doesn't work reliably on some older devices. So limit the
live_status check fo
On 4/20/2016 8:18 PM, Ville Syrjälä wrote:
On Wed, Apr 20, 2016 at 05:42:51PM +0530, Shashank Sharma wrote:
This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel platforms, it seems that live status register i
Hi,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160420]
[cannot apply to v4.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Matt-Roper/Pre
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
> +{
> + int ret = i915_oa_select_metric_set_hsw(dev_priv);
> +
> + if (ret)
> + return ret;
> +
> + I915_WRITE(GDT_CHICKEN_BITS, GT_NOA_ENABL
Hi Ankitprasad,
just a quick heads-up, Rafael asked that the function name
acpi_dev_present() be changed, so there's now a commit queued
for Linux 4.7 to rename it to acpi_dev_found():
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c68ae33e7fb4
It will therefore unfo
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void i915_oa_stream_enable(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.ops.oa_enable(dev_priv);
> +
> + if (dev_priv->perf.oa.periodic)
>
Could someone please take a look and see if the change makes sense at all?
Thanks,
James
-Original Message-
From: Xiong, James
Sent: Wednesday, April 13, 2016 11:09 AM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org; Xiong, James
Subject: [PATCH 1/1] change the o
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int i915_oa_read(struct i915_perf_stream *stream,
> + struct i915_perf_read_state *read_state)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + return dev_priv->perf.oa.ops.read
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + /* Pre-DevBDW: OABUFFER must be set with counters off,
> + * before OASTATUS1, but after OASTATUS2
> + */
> + I915_WRITE(GEN7_OASTATUS2, dev
No one will just come out and just tell us the truth, so that users can
quit wasting our time trying to make your Xen work. Your 4.2 kernel
dumps core on i915, and Xen hangs on disk drive ID.
Why don't you just take down the Xen half of this whole thing, and stop
causing so many people the loss
On Wed, Apr 20, 2016 at 03:23:06PM +0100, Robert Bragg wrote:
> +static struct intel_context *
> +lookup_context(struct drm_i915_private *dev_priv,
> +struct file *user_filp,
> +u32 ctx_user_handle)
> +{
> + struct intel_context *ctx;
> +
> + mutex_lock(&dev_priv->de
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int alloc_oa_buffer(struct drm_i915_private *dev_priv)
> +{
> + struct drm_i915_gem_object *bo;
> + int ret;
> +
> + BUG_ON(dev_priv->perf.oa.oa_buffer.obj);
> +
> + ret = i915_mutex_lock_interruptible(dev_priv-
On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote:
> > Reason I ask is since I noticed a while ago a lot of drivers
> > were using info->fix.smem_start and info->fix.smem_len consistently
> > for their ioremap'd areas
On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > > can be used for rem
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
> +{
> + assert_spin_locked(&dev_priv->perf.hook_lock);
> +
> + if (dev_priv->perf.oa.exclusive_stream->enabled) {
> + unsigned long ctx_i
On Wed, 20 Apr 2016 20:27:55 +0300
Imre Deak wrote:
> Atm, we run the BSpec display core uninit/init sequences twice during
> system suspend/resume. While this shouldn't cause any problem, it's
> redundant, so get rid of the duplicate call.
>
> Signed-off-by: Imre Deak
Reviewed-by: Bob Paauwe
On Wed, 20 Apr 2016 20:27:57 +0300
Imre Deak wrote:
> Right after runtime resume we know that we can re-enable DC5, since we
> just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly
> instead of delaying this until the next time we disable power well 2.
>
> Signed-off-by: Imre
On Wed, 20 Apr 2016 20:27:56 +0300
Imre Deak wrote:
> After suspend-to-ram or -disk we don't know what power state the display
> HW will be, DC0 or DC9 are both possible states, so reset the software
> DC state tracking in these cases. This gets rid of 'DC state mismatch'
> error messages during
On Wed, 20 Apr 2016 20:27:54 +0300
Imre Deak wrote:
> Initially we thought that the platform specific suspend/resume sequences
> can be shared between the runtime and system suspend/resume handlers.
> This turned out to be not true, we have quite a few differences on most
> of the platforms. This
On Wed, 13 Apr 2016 21:27:17 +0300
Ville Syrjälä wrote:
> On Wed, Apr 13, 2016 at 11:19:20AM -0700, Bob Paauwe wrote:
> > On Wed, 13 Apr 2016 11:59:43 +0300
> > Ville Syrjälä wrote:
> >
> > > On Tue, Apr 12, 2016 at 03:52:48PM -0700, Bob Paauwe wrote:
> > > > if the crtc has audio is enable
if the crtc has audio is enabled. Otherwise, when the first atomic
modeset happens it will warn when trying to drop the audio power
domain.
v2: move this to get_crtc_power_domains to be consistent with other
power domain setup (Ville)
Signed-off-by: Bob Paauwe
Cc: Ville Syrjälä
---
drivers
Hi,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160420]
[cannot apply to v4.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Robert-Bragg/Enable
Kabylake was introduced as a derivation of Skylake H0, but when
the support was added to our driver the needed workarounds wasn't
clear on the specs and also our driver wasn't implementing many
of SKL forever workarounds.
Now that workarounds are more clear let's start adding them to
get more stab
Nothing indicates that we need this WA on KBL.
Nor spec or wa_database mentions this being needed or used
on this platform.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
This Workaround is common to gen9 platforms so let's move it to the
right function.
No functional change.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_
On Wed, Apr 13, 2016 at 08:47:53PM +0300, Ander Conselvan de Oliveira wrote:
> This moves the last dpio phy specific code from the encoders to the phy
> specific file.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
On Wed, Apr 13, 2016 at 08:47:52PM +0300, Ander Conselvan de Oliveira wrote:
> The phy code in vlv_pre_enable_dp() and vlv_hdmi_pre_enable() is
> exectly the same, so extract it to intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Jim Bride
> ---
> drivers/gpu/d
On Wed, Apr 13, 2016 at 08:47:51PM +0300, Ander Conselvan de Oliveira wrote:
> The code used by the DP and HDMI paths was very similar, so make them
> share it. Note that this removes the write to signal level registers
> from the HDMI pre pll enable path, but that's OK since those are set
> in vlv
On Wed, Apr 13, 2016 at 08:47:48PM +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
>
> v2: Don't move commen
On Wed, Apr 13, 2016 at 08:47:47PM +0300, Ander Conselvan de Oliveira wrote:
> The same logic is used for DP and HDMI so move it to intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/dr
On 12/04/16 16:18, Chris Wilson wrote:
On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote:
When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he
suggested replacing some use of kmap(i915_gem_object_get_dirty_page())
with a plain i915_gem_object_pin_map(). This raised
On Wed, Apr 13, 2016 at 08:47:46PM +0300, Ander Conselvan de Oliveira wrote:
> The function chv_data_lane_soft_reset() was duplicated in DP and HDMI
> code. Move it to intel_dpio_phy.c.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_
Thanks for the help. I'm sorry regarding the volume, but maybe the
docs page needs an update pointing the appropriate bugtracker
selection(s) unless I'm blind. I didn't know to choose DRI because I'm
just a user.
Regards,
Colin
On Wed, Apr 20, 2016 at 10:06 AM, Jani Nikula
wrote:
> On Wed, 20 A
On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> > The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> > can be used for remapping multiple pages. Extend the helper so that
> > future callers ca
On Wed, Apr 13, 2016 at 08:47:45PM +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.
>
> v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville)
> Signed-off-b
During hibernation, all objects will have had their page contents
written to disk and then restored upon resume. This means that every
page will be dirty and we need to treat all objects as being in the CPU
domain and require their contents to be flushed before use.
At present we only do so for th
On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> can be used for remapping multiple pages. Extend the helper so that
> future callers can use it for larger ranges.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko
On Wed, Apr 20, 2016 at 03:39:02PM +0300, 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
On Wed, Apr 20, 2016 at 09:31:57PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 20, 2016 at 07:19:32PM +0100, Chris Wilson wrote:
> > On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
> > >
> > > Tim Gore
> > > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
> > >
We can hide more details of execlists from higher level code by removing
the explicit call to create an execlist context from execbuffer and
into its first use by execlists.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8
dri
From: Tvrtko Ursulin
With the previous patch having extended the pinned lifetime of
contexts by referencing the previous context from the current
request until the latter is retired (completed by the GPU),
we can now remove usage of execlist retired queue entirely.
This is because the above now
From: Tvrtko Ursulin
This way in the following patch we can disconnect requests
from contexts.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
2 files changed, 4 inser
As the contexts are accessed by the hardware until the switch is completed
to a new context, the hardware may still be writing to the context object
after the breadcrumb is visible. We must not unpin/unbind/prune that
object whilst still active and so we keep the previous context pinned until
the f
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM requ
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: Yishai
The hardware tracks contexts and expects all live contexts (those active
on the hardware) to have a unique identifier. This is used by the
hardware to assign pagefaults and the like to a particular context.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_de
Refactor pinning and unpinning of contexts, such that the default
context for an engine is pinned during initialisation and unpinned
during teardown (pinning of the context handles the reference counting).
Thus we can eliminate the special case handling of the default context
that was required to m
In order to force a reload of the context image upon resume, we first
need to mark its absence on suspend. Currently we are failing to restore
the golden context state and any context w/a to the default context
after resume.
One oversight corrected, is that we had forgotten to reapply the L3
remap
When setting up the overlay page, we pin it into the GGTT (when using
virtual addresses) and store the offset as overlay->flip_addr. Rather
than doing a lookup of the GGTT address everytime, we can use the known
address instead.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko
Instead of allocating a new request when allocating a context, use the
request that initiated the allocation to emit the context
initialisation. This serves two purposes, it makes the initialisation
atomic with first use (simplifying scheduling and our own error
handling). Secondly, it enables us t
Pulled in the few missing details to put everything together in the same
series. Still missing a few r-b through:
[02/19] io-mapping: Specify mapping size for
[05/19] drm/i915: Use i915_vma_pin_iomap on the ringbuffer
[10/19] drm/i915: Rearrange switch_context to load the aliasing
[14/19] drm/i915
Rather than reuse the current location of the context in the global GTT
for its hardware identifier, use the context's unique ID assigned to it
for its whole lifetime.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
drivers/gpu/
In a couple of places, we have an i915_address_space that we know is
really an i915_ggtt that we want to use. Create an inline helper to
convert from the i915_address_space subclass into its container.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Reviewed-by: Joonas Lahtin
The code to switch_mm() is already handled by i915_switch_context(), the
only difference required to setup the aliasing ppgtt is that we need to
emit te switch_mm() on the first context, i.e. when transitioning from
engine->last_context == NULL. This allows us to defer the
initialisation of the GPU
Since we do the l3-remap on context switch, we can remove the redundant
early call to set the mapping prior to performing the first context
switch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i91
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Note that by moving the iounnma
We can use a single MI_LOAD_REGISTER_IMM command packet to write all the
L3 remapping registers, shrinking the number of bytes required to emit
the context switch.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 16 ++
Similarly to i915_gem_object_pin_map on LLC platforms, we can
use the new VMA based io mapping on !LLC to amoritize the cost
of ringbuffer pinning and unpinning.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16 ++
Move the i915_gem_l3_remap function such that it next to the context
switching, which is where we perform the L3 remap.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 31 ---
drivers/gpu/drm/i
On Wed, Apr 20, 2016 at 05:54:36PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix eDP low vswing for Broadwell (rev4)
> URL : https://patchwork.freedesktop.org/series/4499/
> State : warning
>
> == Summary ==
>
> Series 4499v4 drm/i915: Fix eDP low vswing for Broadwel
On Wed, Apr 20, 2016 at 07:19:32PM +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
> >
> > Tim Gore
> > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3
> > 1RJ
> >
> >
> > > -Original Message-
> > > From: Thierry, Michel
On Wed, Apr 20, 2016 at 03:51:49PM +, Gore, Tim wrote:
>
> Tim Gore
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
>
>
> > -Original Message-
> > From: Thierry, Michel
> > Sent: Wednesday, April 20, 2016 4:00 PM
> > To: Gore, Tim; intel-gfx@lists.fre
From: Ville Syrjälä
create_bo_for_fb() expects the drm format as a parameter since
commit 8a1a38661f56 ("lib: Add igt_create_bo_with_dimensions")
but not all callers were updated. Fix that up.
Cc: Tomeu Vizoso
Fixes: 8a1a38661f56 ("lib: Add igt_create_bo_with_dimensions")
Bugzilla: https://bugs
On Wed, Apr 20, 2016 at 03:24:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This way in the following patch we can disconnect requests
> from contexts.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
>
On Wed, Apr 20, 2016 at 08:22:31AM +0300, Ander Conselvan de Oliveira wrote:
> The logic for setting signal levels is used for both HDMI and DP with
> small variations. But it is similar enough to put behind a function
> called from the encoders.
>
> v2: Remove unrelated MST changes due to rebase
== Series Details ==
Series: drm/i915: Fix eDP low vswing for Broadwell (rev4)
URL : https://patchwork.freedesktop.org/series/4499/
State : warning
== Summary ==
Series 4499v4 drm/i915: Fix eDP low vswing for Broadwell
http://patchwork.freedesktop.org/api/1.0/series/4499/revisions/4/mbox/
Tes
basic-flip-vs-dpms and basic-flip-vs-modeset together take roughly 2m
to run. Adjust the duration time to a maximum of 500ms.
Signed-off-by: Marius Vlad
---
tests/kms_flip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 3d44544..fd8
Signed-off-by: Marius Vlad
---
lib/igt_aux.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index c32569f..fe18365 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -671,9 +671,9 @@ void igt_system_suspend_autoresume(void)
igt_ski
It's possible that BIOS enables PHY1 only to read out the GRC value from
it to be used in PHY0 and then disables PHY1. In this case we can't use
the PHY1 GRC value for state verification, so use instead the one in PHY0
always.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
It's possible that BIOS enables PHY0, but it programmes only the first
channel on it. Since we program the PHYs only during driver loading this
is an incorrect configuration from the driver's point of view, since we
may use both channels eventually. Detect this scenario and force
reprogramming the
If we skipped PHY0 initialization because it was already enabled by
BIOS, we still have to wait for the PHY1 GRC calibration as that is
done as part of the PHY0 init.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 21 ++---
1 file changed, 18 insertions(+), 3 del
It's possible that BIOS initializes only a single channel on PHY0 and then
enables it or only enables PHY0 but leaves PHY1 disabled. This patchset
fixes handling of these cases.
CC: Matt Roper
Imre Deak (3):
drm/i915/bxt: Use PHY0 GRC value for HW state verification
drm/i915/bxt: Wait for PH
On Wed, Apr 20, 2016 at 06:09:50PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The fence object used inside the request structure requires a sequence
> number. Although this is not used by the i915 driver itself, it could
> potentially be used by non-i915 code if the fence i
Right after runtime resume we know that we can re-enable DC5, since we
just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly
instead of delaying this until the next time we disable power well 2.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
driv
Atm, we run the BSpec display core uninit/init sequences twice during
system suspend/resume. While this shouldn't cause any problem, it's
redundant, so get rid of the duplicate call.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 10 --
1 file changed, 4 insertions(+), 6
After suspend-to-ram or -disk we don't know what power state the display
HW will be, DC0 or DC9 are both possible states, so reset the software
DC state tracking in these cases. This gets rid of 'DC state mismatch'
error messages during resuming from ram or disk where we expected to be
in DC9 (as s
Initially we thought that the platform specific suspend/resume sequences
can be shared between the runtime and system suspend/resume handlers.
This turned out to be not true, we have quite a few differences on most
of the platforms. This was realized already earlier by Paulo who
uninlined the platf
1 - 100 of 303 matches
Mail list logo
