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
Instead of allocating a new request when allocating a context, use the
request that initiated the allocation to emit the context
initialisation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 39 ++-
We can hide more details of execlists from higher level code by removing
the explicit call to create an execlist context into its first use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8
drivers/gpu/drm/i915/intel_lrc.c | 21 ++---
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
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i9
So, I spent some time reorganising the patches I had for this into a
usable state and found that we needed some more work to keep Braswell
happy with the earlier unpinning. In particular, it needs a stable ctx
descriptor id to keep igt/gem_ctx_switch from quicking hanging.
-Chris
_
Since we do the l3-remap on context switch, and proceed to do a context
switch immediately after manually doing the l3-remap, we can remove the
redundant manual call.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 39 +---
Rather than reuse the current location of the context in the global GTT,
use its unique ID assigned to it for the lifetime of that context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
drivers/gpu/drm/i915/intel_lrc.c| 36 ++--
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
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/
== Series Details ==
Series: drm/i915: Fix oops in vlv_force_pll_on()
URL : https://patchwork.freedesktop.org/series/5888/
State : failure
== Summary ==
Series 5888v1 drm/i915: Fix oops in vlv_force_pll_on()
http://patchwork.freedesktop.org/api/1.0/series/5888/revisions/1/mbox/
Test gem_busy:
On Mon, 2016-04-18 at 14:02 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we're trying to define HSW/BDW power wells by what's not
> included. Let's do it the other way around, so that you can actually
> tell when the power well would get enabled. This will also
Op 18-04-16 om 18:47 schreef Bob Paauwe:
> The i915 driver is now using atomic properties and atomic commit
> to handle the legacy set gamma IOCTL. However, if the driver is
> configured without atomic (nuclear_pageflip = false), it won't
> update the legacy properties for degamma_lut, gamma_lut an
Op 18-04-16 om 18:47 schreef Bob Paauwe:
> The i915 driver is now using atomic properties and atomic commit
> to handle the legacy set gamma IOCTL. However, if the driver is
> configured without atomic (nuclear_pageflip = false), it won't
> update the legacy properties for degamma_lut, gamma_lut an
On Mon, 2016-04-18 at 14:02 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we're using POWER_DOMAIN_MASK as the power domains for the
> display power well on VLV/CHV. That includes all power domains even
> though the disp2d/pipe-a power well is not needed for a lo
On Mon, 2016-04-18 at 14:02 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The always-on well is the same as runtime PM, so we should just
> "enable" it for any power domain. Throw out the usless
> FOO_ALWAYS_ON_DOMAINS defines and just use POWER_DOMAIN_MASK.
>
> Signed-of
On 04/18/2016 07:40 PM, Felix Miata wrote:
> cac...@quantum-sci.com composed on 2016-04-18 19:09 (UTC-0700):
>>
>> I take it there's no SkyLake support on the Xen side, since that starts
>> with kernel 4.4?
>
> Which distro and kernel are you using? Modeset driver built into Xorg
> doesn't work fo
cac...@quantum-sci.com composed on 2016-04-18 19:09 (UTC-0700):
I take it there's no SkyLake support on the Xen side, since that starts
with kernel 4.4?
Which distro and kernel are you using? Modeset driver built into Xorg
doesn't work for you?
"The latest xf86-video-intel driver was causi
On Monday 18 April 2016 09:47 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The power cycle delay starts _after_ turning off the panel power. Do the
msleep after frobbing the pmic panel power gpio.
Also toss in a FIXME about optimizing away needless waits.
Cc: Shobhit Kumar
Cc
I take it there's no SkyLake support on the Xen side, since that starts
with kernel 4.4?
0xF8ED1710.asc
Description: application/pgp-keys
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
On boot after kernel compile I'm getting:
DMAR PTE access not set.
Fast TSC calibration failed.
-- It concludes with "DRHD Fault". And it hangs there.
CentOS 3.10 kernel boots fine with intel_iommu=on. Why?
VT-d and SRIOV capable (Supermicro) mobo, with both on. Bing only has
stuff from 2012
On 03/28/2016 02:39 PM, Joseph Salisbury wrote:
> On 03/02/2016 04:58 PM, Joseph Salisbury wrote:
>> On 02/29/2016 04:33 AM, Jani Nikula wrote:
>>> On Wed, 24 Feb 2016, Joseph Salisbury
>>> wrote:
Hi Sonika,
A kernel bug report was opened against Ubuntu [0]. After a kernel
bi
On 18 April 2016 at 16:53, Daniel Vetter wrote:
> On Mon, Apr 18, 2016 at 03:40:11PM +0100, Emil Velikov wrote:
>> On 18 April 2016 at 13:36, Daniel Vetter wrote:
>> > On Mon, Apr 18, 2016 at 12:09:51PM +0100, Lionel Landwerlin wrote:
>> >> Ping?
>> >>
>> >> On 22/03/16 14:10, Lionel Landwerlin w
From: Ville Syrjälä
intel_pipe_will_have_type() doesn't just look at the passied in
pipe_config, instead it expects there to be a full atomic state behind
it. Obviously that won't go so well when vlv_force_pll_on() just uses a
temp pipe_config. Fix things by using pipe_config->has_dsi_encoder
ins
On ma, 2016-04-18 at 10:15 +0200, Patrik Jakobsson wrote:
> On Fri, Apr 15, 2016 at 10:32:58PM +0300, Imre Deak wrote:
> > The workaround added in c6782b76d31a ("drm/i915/gen9: Reset
> > secondary power
> > well requests left on by DMC/KVMR") needs to be applied on Kabylake
> > too as
> > shown by
On Mon, 18 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating
> after DSI disable. That's what we checked when disabling the clock
> gating when enabling DSI.
>
> Also use the same temporary variable name
== Series Details ==
Series: drm/i915: Wait for power cycle delay after turning off DSI panel power
URL : https://patchwork.freedesktop.org/series/5885/
State : warning
== Summary ==
Series 5885v1 drm/i915: Wait for power cycle delay after turning off DSI panel
power
http://patchwork.freedesk
On Mon, 18 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The power cycle delay starts _after_ turning off the panel power. Do the
> msleep after frobbing the pmic panel power gpio.
>
> Also toss in a FIXME about optimizing away needless waits.
>
> Cc: Shobhit Kumar
> Cc
On Mon, 18 Apr 2016, Chris Wilson wrote:
> [ text/plain ]
> On Mon, Apr 18, 2016 at 06:09:28PM +0300, Joonas Lahtinen wrote:
>> @@ -251,7 +245,7 @@ static int swsci(struct drm_device *dev, u32 function,
>> u32 parm, u32 *parm_out)
>> struct drm_i915_private *dev_priv = dev->dev_private;
>>
== Series Details ==
Series: series starting with [1/3] drm/i915: Do CRT HPD force trigger only when
needed
URL : https://patchwork.freedesktop.org/series/5884/
State : success
== Summary ==
Series 5884v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5884/revisio
On Mon, Apr 18, 2016 at 07:42:00PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 18, 2016 at 12:03:01PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Power domain fixes
> > URL : https://patchwork.freedesktop.org/series/5863/
> > State : failure
> >
> > == Summary ==
>
The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic ve
On Mon, Apr 18, 2016 at 12:03:01PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Power domain fixes
> URL : https://patchwork.freedesktop.org/series/5863/
> State : failure
>
> == Summary ==
>
> Series 5863v1 drm/i915: Power domain fixes
> http://patchwork.freedesktop.or
From: Ville Syrjälä
Check for VLV/CHV instead if !BXT when re-enabling DPOunit clock gating
after DSI disable. That's what we checked when disabling the clock
gating when enabling DSI.
Also use the same temporary variable name in both cases, and toss in a
bit of dev vs. dev_priv cleanup while at
From: Ville Syrjälä
The power cycle delay starts _after_ turning off the panel power. Do the
msleep after frobbing the pmic panel power gpio.
Also toss in a FIXME about optimizing away needless waits.
Cc: Shobhit Kumar
Cc: Jani Nikula
Fixes: fc45e8219907 ("drm/i915: Use the CRC gpio for panel
From: Ville Syrjälä
Supposedly we need to power on the TX wells before CMN well on VLV.
We currently do that when enabling HDMI/DP ports, but when we enable
the CRT port we only power up the CMN well. So if someone enables the
CRT port first, and then HDMI/DP the wells will power up in the suppos
From: Ville Syrjälä
The CRT HPD force trigger will generate a HPD irq. Let's ignore it since
we're already doing the detect and there's no point in scheduling
another one immediately.
This is rather important on VLV since turning on the disp2d power well
will trigger a CRT HPD and when processin
From: Ville Syrjälä
There doesn't seem to be any need to for the force trigger trick every
single time on VLV CRT output. Let's do it the same way as on ILK+, and
do the force trigger only on the first detect after reset.
This means we can actually just call the ILK+ code on VLV. The only
differ
On Mon, Apr 18, 2016 at 01:43:13PM +0200, Maarten Lankhorst wrote:
> Op 18-04-16 om 13:29 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > When a vblank wait times out in intel_atomic_wait_for_vblanks() we just
> > get a cryptic 'WARN_ON(!ret)' backtrace in dmesg. Repace it w
== Series Details ==
Series: drm/i915: Clean up PCI config register handling (rev2)
URL : https://patchwork.freedesktop.org/series/5768/
State : failure
== Summary ==
Series 5768v2 drm/i915: Clean up PCI config register handling
http://patchwork.freedesktop.org/api/1.0/series/5768/revisions/2/
On Mon, Apr 18, 2016 at 03:40:11PM +0100, Emil Velikov wrote:
> On 18 April 2016 at 13:36, Daniel Vetter wrote:
> > On Mon, Apr 18, 2016 at 12:09:51PM +0100, Lionel Landwerlin wrote:
> >> Ping?
> >>
> >> On 22/03/16 14:10, Lionel Landwerlin wrote:
> >> >When extracting the value at full precision
On ma, 2016-04-18 at 13:57 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix a few suspend/resume and driver unload bugs
> (rev3)
> URL : https://patchwork.freedesktop.org/series/5856/
> State : failure
>
> == Summary ==
>
> Series 5856v3 drm/i915: Fix a few suspend/resu
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/overlay: Replace
i915_gem_obj_ggtt_offset() with the known flip_addr (rev2)
URL : https://patchwork.freedesktop.org/series/5865/
State : warning
== Summary ==
Series 5865v2 Series without cover letter
http://patchwork.freedes
On 18/04/16 16:22, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 04:08:55PM +0100, Tvrtko Ursulin wrote:
On 18/04/16 15:54, Chris Wilson wrote:
@@ -3378,6 +3378,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool
wait)
ret = i915_gem_object_put_fence(obj);
On Mon, Apr 18, 2016 at 06:09:28PM +0300, Joonas Lahtinen wrote:
> @@ -251,7 +245,7 @@ static int swsci(struct drm_device *dev, u32 function,
> u32 parm, u32 *parm_out)
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct opregion_swsci *swsci = dev_priv->opregion.swsci;
>
On Mon, Apr 18, 2016 at 04:08:55PM +0100, Tvrtko Ursulin wrote:
> On 18/04/16 15:54, Chris Wilson wrote:
> >@@ -3378,6 +3378,8 @@ static int __i915_vma_unbind(struct i915_vma *vma,
> >bool wait)
> > ret = i915_gem_object_put_fence(obj);
> > if (ret)
> >
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160418]
[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/Chris-Wilson
On 18/04/16 15:54, Chris Wilson wrote:
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
On Mon, Apr 18, 2016 at 10:00:36AM -0400, Lyude wrote:
> While VGA hotplugging worked(ish) before, it looks like that was mainly
> because we'd unintentionally enable it in
> valleyview_crt_detect_hotplug() when we did a force trigger. This
> doesn't work reliably enough because whenever the displa
Do not use magic numbers, do not prefix stuff with "PCI_", do not
declare registers in implementation files. Also move the PCI
registers under correct comment in i915_reg.h.
v2:
- Consistently use BSM (not BDSM or other variants from PRM) (Chris)
- Also include register address to help identify th
On Mon, Apr 18, 2016 at 02:45:54PM +0300, Imre Deak wrote:
> During system resume we depended on pci_enable_device() also putting the
> device into PCI D0 state. This won't work if the PCI device was already
> enabled but still in D3 state. This is because pci_enable_device() is
> refcounted and wi
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
On 18 April 2016 at 13:36, Daniel Vetter wrote:
> On Mon, Apr 18, 2016 at 12:09:51PM +0100, Lionel Landwerlin wrote:
>> Ping?
>>
>> On 22/03/16 14:10, Lionel Landwerlin wrote:
>> >When extracting the value at full precision (16 bits), no need to
>> >round the value.
>> >
>> >This was spotted by Ja
== Series Details ==
Series: Add USB typeC based DP support for BXT platform (rev5)
URL : https://patchwork.freedesktop.org/series/1731/
State : failure
== Summary ==
Series 1731v5 Add USB typeC based DP support for BXT platform
http://patchwork.freedesktop.org/api/1.0/series/1731/revisions/5/
On Mon, Apr 18, 2016 at 04:37:12PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-04-18 at 12:14 +0100, Chris Wilson wrote:
> > 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
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA ge
== Series Details ==
Series: drm/i915: Fix a few suspend/resume and driver unload bugs (rev3)
URL : https://patchwork.freedesktop.org/series/5856/
State : failure
== Summary ==
Series 5856v3 drm/i915: Fix a few suspend/resume and driver unload bugs
http://patchwork.freedesktop.org/api/1.0/seri
On ma, 2016-04-18 at 12:14 +0100, Chris Wilson wrote:
> 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
> C
On ma, 2016-04-18 at 14:11 +0100, Chris Wilson wrote:
> On Mon, Apr 18, 2016 at 03:51:20PM +0300, Joonas Lahtinen wrote:
> >
> > On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> > >
> > > Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
> > >
> > > v2: use dev_priv directly fo
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/overlay: Replace
i915_gem_obj_ggtt_offset() with the known flip_addr
URL : https://patchwork.freedesktop.org/series/5865/
State : warning
== Summary ==
Series 5865v1 Series without cover letter
http://patchwork.freedesktop.or
On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> We need to kunmap pt_vaddr and not pt itself, otherwise we end up
> mapping a bunch of pages without ever unmapping them.
>
It's always a good idea to use 'git blame' to figure out the bug
inducing commit, and include that information + CC'i
On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> If we are not in FULL_48BIT_PPGTT mode then we really shouldn't
> continue on with our allocations, given that the call to free_dpd would
> bail early without freeing everything, thus leaking memory.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtine
On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> For the gen6/gen8_allocate_va_range functions remove the WARN_ON range
> sanity checks in favour of simply hardening the allocation paths. This
> also fixes the inconsistency in which we don't always handle the
> potential overflow in our chec
On Mon, Apr 18, 2016 at 03:51:20PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> > Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
> >
> > v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen)
> >
> > Cc: Joonas Lahtinen
>
> Revie
Op 14-04-16 om 03:58 schreef Matt Roper:
> On Tue, Apr 05, 2016 at 11:35:31AM +0200, Maarten Lankhorst wrote:
>> Op 01-04-16 om 03:46 schreef Matt Roper:
>>> We eventually want to calculate watermark values at atomic 'check' time
>>> instead of atomic 'commit' time so that any requested configurati
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. Sometimes
Split out of bxt_ddi_pll_select() the logic that calculates the pll
dividers and dpll_hw_state into a new function that doesn't depend on
crtc state. This will be used for enabling the port pll when doing
upfront link training.
v1:
* Rebased on top of intel_dpll_mgr.c (Durga)
* Initial version fro
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 sce
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.
v4:
* Added ERR_PTR as a return value in kernel Doc comment (Ander)
v3:
* Added kernel Doc and removed an invalid comment (Ander)
* Rebased on t
On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
>
> v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen)
>
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm
On Mon, Apr 18, 2016 at 11:07:43AM +0100, Lionel Landwerlin wrote:
> On 12/04/16 17:07, Daniel Vetter wrote:
> >On Tue, Apr 12, 2016 at 01:51:02PM +0100, Lionel Landwerlin wrote:
> >>On 12/04/16 12:57, Daniel Vetter wrote:
> >>>On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> >>
On Mon, Apr 18, 2016 at 12:09:51PM +0100, Lionel Landwerlin wrote:
> Ping?
>
> On 22/03/16 14:10, Lionel Landwerlin wrote:
> >When extracting the value at full precision (16 bits), no need to
> >round the value.
> >
> >This was spotted by Jani when running sparse. Unfortunately this fix
> >doesn't
On Mon, Apr 18, 2016 at 02:29:33PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Vblank waits timing out is no a normal thing to happen, so let's inform
> people when it happens.
>
> Signed-off-by: Ville Syrjälä
Applied to drm-misc, let's see how much it blows up. We /s
== Series Details ==
Series: drm/i915: Remove a couple pointless WARN_ONs (rev2)
URL : https://patchwork.freedesktop.org/series/5772/
State : failure
== Summary ==
Series 5772v2 drm/i915: Remove a couple pointless WARN_ONs
http://patchwork.freedesktop.org/api/1.0/series/5772/revisions/2/mbox/
On 18 April 2016 at 14:09, Daniel Vetter wrote:
> On Wed, Mar 09, 2016 at 04:57:37PM +0100, Tomeu Vizoso wrote:
>> From: Micah Fedke
>>
>> This function uses an intel-specific ioctl to fetch a mapping between pipes
>> and
>> crtc ids, but this technique is outdated as the crtc id is now always
>
On Mon, Apr 18, 2016 at 02:49:26PM +0300, Jani Nikula wrote:
> On Mon, 18 Apr 2016, Dave Gordon wrote:
> > The GuC changes are OK, and we might as well convert "dev_priv" to
> > "i915" at the same time, if that's now the preferred name.
>
> Hmph, I see that "struct drm_i915_private *i915" is alr
On Wed, Mar 09, 2016 at 04:57:37PM +0100, Tomeu Vizoso wrote:
> From: Micah Fedke
>
> This function uses an intel-specific ioctl to fetch a mapping between pipes
> and
> crtc ids, but this technique is outdated as the crtc id is now always
> equivalent to its index in the array of crtcs returned
On 18/04/16 12:56, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 12:14:02PM +0100, Chris Wilson wrote:
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
On Mon, Apr 18, 2016 at 02:48:21PM +0300, Imre Deak wrote:
> While we disable runtime PM and with that display power well support if
> the DMC firmware isn't loaded, we still want to disable power wells
> during system suspend and driver unload. So drop/reacquire the
> corresponding power refcount
On 18/04/16 12:14, Chris Wilson wrote:
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
== Series Details ==
Series: drm/i915: Power domain fixes
URL : https://patchwork.freedesktop.org/series/5863/
State : failure
== Summary ==
Series 5863v1 drm/i915: Power domain fixes
http://patchwork.freedesktop.org/api/1.0/series/5863/revisions/1/mbox/
Test gem_ringfill:
Subgroup ba
On 18/04/16 12:14, Chris Wilson wrote:
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:
On Mon, Apr 18, 2016 at 12:14:02PM +0100, Chris Wilson wrote:
> 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 invocati
On Mon, 18 Apr 2016, Dave Gordon wrote:
> The GuC changes are OK, and we might as well convert "dev_priv" to
> "i915" at the same time, if that's now the preferred name.
Hmph, I see that "struct drm_i915_private *i915" is already being used
in a few places. This is more than a little confusing s
While we disable runtime PM and with that display power well support if
the DMC firmware isn't loaded, we still want to disable power wells
during system suspend and driver unload. So drop/reacquire the
corresponding power refcount during suspend/resume and driver unloading.
This also means we have
During system resume we depended on pci_enable_device() also putting the
device into PCI D0 state. This won't work if the PCI device was already
enabled but still in D3 state. This is because pci_enable_device() is
refcounted and will not change the HW state if called with a non-zero
refcount. Leav
On Mon, Apr 18, 2016 at 12:28:43PM +0100, Dave Gordon wrote:
> On 18/04/16 11:25, Chris Wilson wrote:
> >On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
> >>With the new i915_gem_obj_pin_map() interface, it makes sense to keep
> >>GuC objects (which are always pinned in memory and in t
Because bufmgr is currently a i915-only thing and it's only needed in a
subset of the subtests, require it only in the subtests that actually
need it so that the other subtests aren't skipped without a reason.
Signed-off-by: Tomeu Vizoso
---
tests/kms_flip.c | 12 ++--
1 file changed, 1
As the test doesn't actually need tiled BOs, drop the tiled formats so
the test can run on drivers other than i915.
Signed-off-by: Tomeu Vizoso
---
tests/kms_flip_event_leak.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_flip_event_leak.c b/tests/kms_flip_ev
So that this test can be run in drivers other than i915.
Signed-off-by: Tomeu Vizoso
---
tests/kms_flip_event_leak.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_flip_event_leak.c b/tests/kms_flip_event_leak.c
index 0a4a755ee954..a1389b4c5e1d 100644
--- a/te
So that this test can be run in drivers other than i915.
Signed-off-by: Tomeu Vizoso
---
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 58b167d46d90..dc251e902bef 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
Batchbuffers are only needed in the subtest that does the blit on the
GPU, so move that dependency into it so the other subtest can be ran on
!i915.
Signed-off-by: Tomeu Vizoso
---
tests/kms_render.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/test
Op 18-04-16 om 13:29 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> When a vblank wait times out in intel_atomic_wait_for_vblanks() we just
> get a cryptic 'WARN_ON(!ret)' backtrace in dmesg. Repace it with
> something that tells you what actually happened.
>
> Cc: Maarten Lankho
So the test runs on other drivers, drop the usage of the i915-specific
DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID ioctl.
Wait for a vblank event on pipe0 and if we get it, then the test can
proceed (code copied from kms_vblank).
Signed-off-by: Tomeu Vizoso
---
tests/drm_read.c | 44 +
Hi,
these patches allow a few more tests to run on drivers other than i915,
mainly by removing the last usage of
DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID and removing superfluous dependencies
on bufmgr and tiled BOs.
Thanks,
Tomeu
Tomeu Vizoso (7):
tests/drm_read: Drop DRM_IOCTL_I915_GET_PIPE_FRO
Because attempts to create a tiled BO will cause a igt_require call to
fail on drivers that don't support tiling, do so in the subtest that
actually needs it so that other subtests aren't skipped without reason.
Signed-off-by: Tomeu Vizoso
---
tests/kms_flip.c | 11 +++
1 file changed,
Hi Bob,
Thanks for spotting this.
Reviewed-by: Lionel Landwerlin
On 11/04/16 18:41, Bob Paauwe wrote:
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. Witho
These tests should skip properly on platforms not supporting color
management & pipe CRC. They should also run within 10s. So it makes
sense to have run by the BAT as we missed some regressions lately.
Signed-off-by: Lionel Landwerlin
---
tests/Makefile.sources |2 +-
tests/kms_pipe_co
From: Ville Syrjälä
Vblank waits timing out is no a normal thing to happen, so let's inform
people when it happens.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/
From: Ville Syrjälä
When a vblank wait times out in intel_atomic_wait_for_vblanks() we just
get a cryptic 'WARN_ON(!ret)' backtrace in dmesg. Repace it with
something that tells you what actually happened.
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_displ
1 - 100 of 164 matches
Mail list logo
