== Series Details ==
Series: Try to fix MST regression with DDI IO power domains
URL : https://patchwork.freedesktop.org/series/20345/
State : failure
== Summary ==
Series 20345v1 Try to fix MST regression with DDI IO power domains
https://patchwork.freedesktop.org/api/1.0/series/20345/revisio
On 27/02/2017 23:41, Chris Wilson wrote:
Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ---
1 file chan
On Mon, 2017-02-27 at 22:38 +0200, Ville Syrjälä wrote:
> On Fri, Feb 24, 2017 at 04:19:59PM +0200, Ander Conselvan de Oliveira wrote:
> > According to bspec, the DDI IO power domains should be enabled after
> > enabling the DPLL and mapping it to the DDI. The current order doesn't
> > seem to crea
Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to
Kernel panic - not syncing: Timeout: Not all CPUs en
The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
by calling the post_disable hook on the intel_dig_port instead of
duplicating that code.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
Hi,
Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") seems to have broken MST. Here's an untested fix (I
don't have the right hardware to test this at the moment).
Thanks,
Ander
Ander Conselvan de Oliveira (2):
drm/i915: Enable DDI IO power domains in the
We suggest GLK could disable pooled EUs for 2x6 configurations too.
As I understand, 2x6 a pool must consist of a complete subslice, 12EUs, right?
If so, only 64K SLM are valid, I am afraid it may affect some case's
performance.
> -Original Message-
> From: Conselvan De Oliveira, Ander
>
On 17-02-23 16:18:16, Chris Wilson wrote:
Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.
Use this at your discr
On 17-02-27 17:13:41, Ville Syrjälä wrote:
On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This
>On 02/27/2017 10:13 AM, Xu, Terrence wrote:
>> [Xu, Terrence] Yes the root is needed for all our "echo" related commands,
>can I suppose the case is running under root privilege? Or need to return
>"skip" when it is not under root privilege?
>>
>
>Right, seems I was a bit confused there and there
== Series Details ==
Series: drm/i915: Force uncached PPAT for debugging purposes.
URL : https://patchwork.freedesktop.org/series/20334/
State : success
== Summary ==
Series 20334v1 drm/i915: Force uncached PPAT for debugging purposes.
https://patchwork.freedesktop.org/api/1.0/series/20334/rev
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd/
Joe Perches (2):
drm: Use pr_cont where appropriate
gpu: drm: Convert printk(KERN_ to pr_
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +-
drivers/gpu/drm/amd/amd
On 17-02-27 17:12:07, Rodrigo Vivi wrote:
Many screen corruptions and hangs in the past were somehow
related to the caches. In many situations forcing the uncached
was useful at least to narrow down the issue by confirming it
was cache related.
Instead of having to hardcode it everytime that we
Many screen corruptions and hangs in the past were somehow
related to the caches. In many situations forcing the uncached
was useful at least to narrow down the issue by confirming it
was cache related.
Instead of having to hardcode it everytime that we suspect on
this table let's provide a mechan
== Series Details ==
Series: drm/i915: Consolidate reporting of "missed breadcrumbs"
URL : https://patchwork.freedesktop.org/series/20330/
State : failure
== Summary ==
Series 20330v1 drm/i915: Consolidate reporting of "missed breadcrumbs"
https://patchwork.freedesktop.org/api/1.0/series/20330
On Fri, Feb 24, 2017 at 12:45:54PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > If we are setting the context and do inhibit the restoration from the
> > context image, also forgo applying the set-context w/a.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915
Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff
== Series Details ==
Series: drm/i915: Avoiding recursing on ww_mutex inside shrinker
URL : https://patchwork.freedesktop.org/series/20328/
State : failure
== Summary ==
Series 20328v1 drm/i915: Avoiding recursing on ww_mutex inside shrinker
https://patchwork.freedesktop.org/api/1.0/series/203
On Mon, 27 Feb 2017 22:27:58 +0100,
Rafael J. Wysocki wrote:
>
> On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
> > On Mon, 27 Feb 2017 15:25:32 +0100,
> > Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 27-02-17 14:30, Rafael J. Wysocki wrote:
> >> > +Mika & Andy
> >> >
> >> > On Saturday,
We have to avoid taking ww_mutex inside the shrinker as we use it as a
plain mutex type and so need to avoid recursive deadlocks:
[ 602.771969] =
[ 602.771970] [ INFO: inconsistent lock state ]
[ 602.771973] 4.10.0gpudebug+ #122 Not tainted
[ 602.771974] ---
On Mon, Feb 27, 2017 at 09:22:31PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/4] drm/i915: Report both waiters and
> success from intel_engine_wakeup()
> URL : https://patchwork.freedesktop.org/series/20325/
> State : success
>
> == Summary ==
>
> Se
Hi,
On 27-02-17 18:06, Bob Paauwe wrote:
On Sat, 25 Feb 2017 11:37:50 +0100
Hans de Goede wrote:
Hi,
On 24-02-17 18:00, Bob Paauwe wrote:
On Mon, 20 Feb 2017 15:08:41 +0100
Hans de Goede wrote:
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_en
On Mon, Feb 27, 2017 at 10:58 PM, Hans de Goede wrote:
> Hi,
>
>
> On 27-02-17 22:49, Rafael J. Wysocki wrote:
>>
>> On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 27-02-17 22:25, Rafael J. Wysocki wrote:
On Mon, Feb 27, 2017 at 3:25 PM, Hans d
Hi,
On 27-02-17 22:49, Rafael J. Wysocki wrote:
On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede wrote:
Hi,
On 27-02-17 22:25, Rafael J. Wysocki wrote:
On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede
wrote:
Hi,
On 27-02-17 14:30, Rafael J. Wysocki wrote:
+Mika & Andy
On Saturday, Fe
On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede wrote:
> Hi,
>
>
> On 27-02-17 22:25, Rafael J. Wysocki wrote:
>>
>> On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 27-02-17 14:30, Rafael J. Wysocki wrote:
+Mika & Andy
On Saturday, Febr
Hi,
On 27-02-17 22:25, Rafael J. Wysocki wrote:
On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede wrote:
Hi,
On 27-02-17 14:30, Rafael J. Wysocki wrote:
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
Several cherrytrail devices (all of which ship with windows
On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
> On Mon, 27 Feb 2017 15:25:32 +0100,
> Hans de Goede wrote:
>>
>> Hi,
>>
>> On 27-02-17 14:30, Rafael J. Wysocki wrote:
>> > +Mika & Andy
>> >
>> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
>> >> Several cherrytrail device
On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede wrote:
> Hi,
>
>
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
>>
>> +Mika & Andy
>>
>> On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
>>>
>>> Several cherrytrail devices (all of which ship with windows 10) hide the
>>> lpss pwm contr
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Report both waiters and success
from intel_engine_wakeup()
URL : https://patchwork.freedesktop.org/series/20325/
State : success
== Summary ==
Series 20325v1 Series without cover letter
https://patchwork.freedesktop.org/api/
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt du
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in th
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the
On Fri, Feb 24, 2017 at 04:19:59PM +0200, Ander Conselvan de Oliveira wrote:
> According to bspec, the DDI IO power domains should be enabled after
> enabling the DPLL and mapping it to the DDI. The current order doesn't
> seem to create problems with Skylake and Kabylake, but causes enable
> timeo
On 27/02/2017 14:13, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 02:06:58PM +, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
On 27/02/2017 13:24, Chris Wilson wrote:
if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
@@ -67,7 +
On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote:
> On Wed, Feb 22, 2017 at 12:01:12AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> > >
> > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2017-02-15 at 16:53 +0530, Arc
== Series Details ==
Series: drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
URL : https://patchwork.freedesktop.org/series/19959/
State : success
== Summary ==
Series 19959v1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
https://patchwork.freedesktop.org/api/1.0/se
On Mon, 27 Feb 2017 11:22:32 +0100
Hans de Goede wrote:
> On some devices only MIPI PORT C is used, in this case checking the
> MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
> on VLV/CHT) will result in false positive "DSI LP not going Low" errors
> as this checks the PORT A
On Sat, 25 Feb 2017, Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
>> On Mon, 20 Feb 2017 15:08:43 +0100
>> Hans de Goede wrote:
>>
>>> For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before
>>> MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop.
>>
>> Isn't this only for comm
On Mon, 27 Feb 2017, Bob Paauwe wrote:
> On Sat, 25 Feb 2017 11:42:09 +0100
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 24-02-17 18:02, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:42 +0100
>> > Hans de Goede wrote:
>> >
>> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY
On Mon, 27 Feb 2017, Bob Paauwe wrote:
> On Sat, 25 Feb 2017 11:37:50 +0100
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 24-02-17 18:00, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:41 +0100
>> > Hans de Goede wrote:
>> >
>> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same t
On Sat, 25 Feb 2017 11:47:32 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:44 +0100
> > Hans de Goede wrote:
> >
> >> According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
> >> on enable for cmd-mode, just like we alread
On Mon, Feb 27, 2017 at 06:34:26PM +0200, Jani Nikula wrote:
> On Thu, 23 Feb 2017, Chris Wilson wrote:
> > After initiating a sideband transaction, we only want to wait for the
> > transaction to become idle. If, as we are, we wait for both the busy
> > and error flag to clear, if an error is rai
On Sat, 25 Feb 2017 11:49:09 +0100
Hans de Goede wrote:
> HI,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:45 +0100
> > Hans de Goede wrote:
> >
> >> For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
> >> we should not also delay ourselves otherwis
== Series Details ==
Series: series starting with [1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail
URL : https://patchwork.freedesktop.org/series/20314/
State : success
== Summary ==
Series 20314v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20314/revisions/1/
On Sat, 25 Feb 2017 11:42:09 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:42 +0100
> > Hans de Goede wrote:
> >
> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
> >> before sending SHUTDOWN, where as for v3 V
On Sat, 25 Feb 2017 11:37:50 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:41 +0100
> > Hans de Goede wrote:
> >
> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
> >> we call intel_panel_enable_backlight() /
On Sat, 25 Feb 2017 11:35:03 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:37 +0100
> > Hans de Goede wrote:
> >
> >> MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons:
> >> 1) The reset should already be asserted be
On Mon, Feb 27, 2017 at 05:19:21PM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> > On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > > Handle debugfs override edid
On Thu, 23 Feb 2017, Chris Wilson wrote:
> After initiating a sideband transaction, we only want to wait for the
> transaction to become idle. If, as we are, we wait for both the busy
> and error flag to clear, if an error is raised we just spin until the
> timeout. Once the hw is idle, we can the
On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > Handle debugfs override edid and firmware edid at the low level to
> > > transparently and completel
On Mon, Feb 27, 2017 at 03:52:12PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB
> invalidate on switching contexts
> URL : https://patchwork.freedesktop.org/series/20313/
> State : success
>
> == Summary ==
>
> Series
Hi Dave,
drm-misc-next-fixes-2017-02-27:
Misc fixes for the 4.11 merge window.
- vmwgfx drm_control node compat patch
- rockchip&zte fixes
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
massive fumble. oops)
Nothing major outstanding afaik.
Cheers, Daniel
The followin
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate
on switching contexts
URL : https://patchwork.freedesktop.org/series/20313/
State : success
== Summary ==
Series 20313v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
On Fri, Feb 24, 2017 at 06:26:10PM +0100, Michal Wajdeczko wrote:
> On Fri, Feb 24, 2017 at 04:40:01PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_init_hw() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the lo
== Series Details ==
Series: series starting with [1/3] drm/i915: Start splitting out
i915_gem_object routines
URL : https://patchwork.freedesktop.org/series/20312/
State : warning
== Summary ==
Series 20312v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20312/
On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
> On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engin
On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > Handle debugfs override edid and firmware edid at the low level to
> > transparently and completely replace the real edid. Previously, we
> > practically only used the m
On Mon, Feb 27, 2017 at 02:52:27PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v5,1/4] drm/i915: Report both waiters and
> success from intel_engine_wakeup()
> URL : https://patchwork.freedesktop.org/series/20310/
> State : failure
>
> == Summary ==
>
> Se
== Series Details ==
Series: series starting with [v5,1/4] drm/i915: Report both waiters and success
from intel_engine_wakeup()
URL : https://patchwork.freedesktop.org/series/20310/
State : failure
== Summary ==
Series 20310v1 Series without cover letter
https://patchwork.freedesktop.org/api/
On Mon, 27 Feb 2017 15:25:32 +0100,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
> > +Mika & Andy
> >
> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> >> Several cherrytrail devices (all of which ship with windows 10) hide the
> >> lpss pwm con
On 27/02/2017 10:21, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:
On 27/02/2017 10:06, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote:
On 22/02/2017 08:44, Chris Wilson wrote:
I also think that's an argument for imp
Hi,
On 27-02-17 14:30, Rafael J. Wysocki wrote:
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, No
On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behavio
To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
On Mon, Feb 27, 2017 at 02:06:58PM +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
> >
> > On 27/02/2017 13:24, Chris Wilson wrote:
> > > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> > >@@ -67,7 +76,7 @@ static void intel_breadc
On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
>
> On 27/02/2017 13:24, Chris Wilson wrote:
> > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> >@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
> > * to process the pending
== Series Details ==
Series: GuC Scrub vol. 1 (rev7)
URL : https://patchwork.freedesktop.org/series/16856/
State : failure
== Summary ==
In file included from drivers/gpu/drm/i915/i915_drv.h:60:0,
from drivers/gpu/drm/i915/i915_gem_execbuffer.c:37:
drivers/gpu/drm/i915/intel_u
No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c
We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuopp
We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to in
On 27/02/2017 13:24, Chris Wilson wrote:
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent b
On 02/27/2017 10:13 AM, Xu, Terrence wrote:
[Xu, Terrence] Yes the root is needed for all our "echo" related commands, can I suppose
the case is running under root privilege? Or need to return "skip" when it is not under
root privilege?
Right, seems I was a bit confused there and there are
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> Several cherrytrail devices (all of which ship with windows 10) hide the
> lpss pwm controller in ACPI, typically the _STA method looks like this:
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
>
To begin with move obj->mm related operations to i915_gem_object.c, in
preparation for future tweaks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h| 107 --
drivers/gpu/drm/i915/i915_gem.c
Check that we can retrieve the right page for a random index, and that
we can map the whole object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_object.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 405 +
.../gpu/drm/i915/selftes
In the next patch, we will allow for obj->mm.__pages to be populated
asynchronously. This means that simply acquiring a pages_pin_count is no
longer sufficient to be sure the pages are there, we need to acquire the
pin (to prevent the pages from disappearing again) and then wait for the
completion.
Currently we have a heavyweight EAGAIN loop round tripping to userspace
to handle asynchronous loading. However, we now have fences to handle
asynchronous execution. Fun times ahead. For starters, let's move the
current asynchronous get_pages onto a more secure footing.
-Chris
On Mon, 27 Feb 2017, Joonas Lahtinen wrote:
> On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
>> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>>
>> Using the parameter disabled version checks and loads desired firmware
>> instead of the default one.
>>
>> Cc:
On Sun, 26 Feb 2017, Enrico Mioso wrote:
> Hello. I am not using this computer actively and can't report easily
> on the state of the screen. Still, I observed the following situation
> in the system's dmesg: running the stock Archlinux Kernel. This is an
> Apple MacMini system, booted via an EF
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in th
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt du
Chris Wilson writes:
> On Wed, Feb 15, 2017 at 03:52:59PM +0200, Mika Kuoppala wrote:
>> Certain Baytrails, namely the 4 cpu core variants, have been
>> plaqued by spurious system hangs, mostly occurring with light loads.
>>
>> Multiple bisects by various people point to a commit which changes t
Michał Winiarski writes:
> Used by production device:
> Intel(R) Iris(TM) Graphics P555
>
> Cc:
> Cc: Mika Kuoppala
> Cc: Rodrigo Vivi
> Signed-off-by: Michał Winiarski
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: Mika Kuoppala
Pushed to dinq, thanks for patch and review.
-Mika
> ---
>
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Only unwind the local pgtable
layer if empty
URL : https://patchwork.freedesktop.org/series/20303/
State : success
== Summary ==
Series 20303v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/203
On ma, 2017-02-27 at 10:21 +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:
> > Perhaps you could say what kind of optimisation you have in mind to
> > save me guessing? :)
>
> I was thinking you would like an inactivity timer. Or we could have a
> separ
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.
v2: fi
On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>
> Using the parameter disabled version checks and loads desired firmware
> instead of the default one.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Michal Wi
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
v2: remove second declaration, reorder (M. Wajdeczko)
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 137 +
As we track whether a vma has been inserted into the drm_mm using the
vma->flags, if we fail to bind the vma into the GTT we do not update
those bits and will attempt to reinsert the vma into the drm_mm on
future passes. To prevent that, we want to unwind i915_vma_insert() if
we fail in our attempt
If we fail to allocate the ppgtt range after allocating the pages for
the vma, we should unwind the local allocation before reporting back the
failure.
Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
dri
Only if we allocated the layer and the lower level failed should we
remove this layer when unwinding. Otherwise we ignore the overlapping
entries by overwriting the old layer with scratch.
Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
Fixes: e2b763caa6eb ("drm/i915: Remove
On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
> preparation (fetch + initial parsing).
>
> This change separates out select steps, so those can be called by
> the sanitize_options().
>
> Then, during the init_fw()
== Series Details ==
Series: drm/i915/skl: Add missing SKL ID (rev3)
URL : https://patchwork.freedesktop.org/series/3537/
State : success
== Summary ==
Series 3537v3 drm/i915/skl: Add missing SKL ID
https://patchwork.freedesktop.org/api/1.0/series/3537/revisions/3/mbox/
fi-bdw-5557u total
On 22 February 2017 at 15:25, Robert Bragg wrote:
> A minor improvement to debugging output
>
> Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On pe, 2017-02-24 at 16:39 +0100, Arkadiusz Hiler wrote:
> Instead of calling intel_guc_init() and intel_huc_init() one by one this
> patch introduces intel_uc_init_fw() function that calls them both.
>
> Called functions are renamed accordingly.
>
> Trying to have subject_verb_object ordering an
On 25 February 2017 at 23:25, Chris Wilson wrote:
> If we fail to allocate the ppgtt range after allocating the pages for
> the vma, we should unwind the local allocation before reporting back the
> failure.
>
> Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
> Signed-off-by: Chris
1 - 100 of 136 matches
Mail list logo
