Hi,
Please pull current GVT-g device model fixes.
Thanks.
---
The following changes since commit 8be8f4a9a9ce48d545512ef7299da607401f3879:
Merge tag 'gvt-next-kvmgt-framework' of https://github.com/01org/gvt-linux
into drm-intel-next-queued (2016-11-10 19:07:30 +0100)
are available in the
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, November 16, 2016 3:07 PM
> To: He, Min
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: fix the dequeue logic for
> single_port_submission context
>
> On Wed
On Tue, Nov 15, 2016 at 02:36:19PM -0800, Matt Roper wrote:
> If we find that we're sharing the cursor, we wind up bailing out of
> __sna_get_cursor() before the fb_to_cursor transform is computed. For
> rotated displays, this can prevent the hotspot transformation from
> happening properly, so th
On Tue, Nov 15, 2016 at 03:56:09PM -0800, Manasi Navare wrote:
> On Tue, Nov 15, 2016 at 08:49:21AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > > + * If userspace is not aware of this property, the user experience is
> > > the same
> > > + * a
On Tue, Nov 15, 2016 at 05:13:43PM -0800, Manasi Navare wrote:
> On Tue, Nov 15, 2016 at 08:53:27AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > > In the usual working scenarios, this property is "Good".
> > > If something fails during modeset,
On Wed, Nov 16, 2016 at 07:03:42AM +, He, Min wrote:
>
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Wednesday, November 16, 2016 2:52 PM
> > To: He, Min
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915:
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, November 16, 2016 2:52 PM
> To: He, Min
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: fix the dequeue logic for
> single_port_submission context
>
> On Wed,
On Wed, Nov 16, 2016 at 02:11:16PM +0800, Min He wrote:
> For a singl_port_submission context, it can only be submitted to port 0,
> and there shouldn't be any other context in port 1 at the same time.
> This patch is to implement the correct logic in execlists_dequeue.
There's a simpler fix. (Oth
== Series Details ==
Series: drm/i915: fix the dequeue logic for single_port_submission context
URL : https://patchwork.freedesktop.org/series/15391/
State : success
== Summary ==
Series 15391v1 drm/i915: fix the dequeue logic for single_port_submission
context
https://patchwork.freedesktop.o
For a singl_port_submission context, it can only be submitted to port 0,
and there shouldn't be any other context in port 1 at the same time.
This patch is to implement the correct logic in execlists_dequeue.
Signed-off-by: Min He
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/intel_lrc.c
> Gen8+ have 64 bit GTT entries, so we need to allocate twice as much
> space for the GTT table in order to cover the same number of GTT
> pages. Fixes sporadic page-fault crashes on the simulator.
> ---
> tools/aubdump.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions
On Wed, Nov 16, 2016 at 6:55 AM, Hugh Dickins wrote:
> On Mon, 14 Nov 2016, akash goel wrote:
>> On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
>> > On 11/10/2016 12:09 PM, Hugh Dickins wrote:
>> >> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
>> >>> @@ -4185,6 +4189,8 @@ struct drm_i915_
In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send hotplug uevent
so that userspace that is aware of this property can take an
ap
On Mon, 14 Nov 2016, akash goel wrote:
> On Thu, Nov 10, 2016 at 1:00 PM, Goel, Akash wrote:
> > On 11/10/2016 12:09 PM, Hugh Dickins wrote:
> >> On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> >>> @@ -4185,6 +4189,8 @@ struct drm_i915_gem_object *
> >>>
> >>> mask = GFP_HIGHUSER | __GFP
On Tue, Nov 15, 2016 at 08:53:27AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > In the usual working scenarios, this property is "Good".
> > If something fails during modeset, the DRM driver can
> > set the link status to "Bad", prune the mode lis
== Series Details ==
Series: HuC Loading Patches (rev3)
URL : https://patchwork.freedesktop.org/series/15135/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/gvt/trace_points.o
LD drivers/tty/serial/8250/8250.o
CC [M] drivers/gpu/drm/i915/gvt/firmware.o
CC [M] drivers
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: b9876d5061a068ba647c8b9923aff8c975bb73a3
commit: d6b0f626375739b1faa2d9dfbca335a923b2a760 [45/47] drm/irq: Unexport
drm_vblank_count
config: x86_64-randconfig-x008-201646 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6
From: Peter Antoine
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before t
On Tue, Nov 15, 2016 at 08:49:21AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > In the usual working scenarios, this property is "Good".
> > If something fails during modeset, the DRM driver can
> > set the link status to "Bad", prune the mode lis
>-Original Message-
>From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
>Sent: Tuesday, November 15, 2016 2:27 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Alex Dai ; Peter Antoine
>Subject: Re: [Intel-gfx] [PATCH-v11] drm/i915/huc: Add HuC fw loading supp
>-Original Message-
>From: Mcgee, Jeff
>Sent: Tuesday, November 15, 2016 2:46 PM
>To: Srivatsa, Anusha
>Cc: Tvrtko Ursulin ; Ursulin, Tvrtko
>; intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
>
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel
>parameter into one
>
>O
If we find that we're sharing the cursor, we wind up bailing out of
__sna_get_cursor() before the fb_to_cursor transform is computed. For
rotated displays, this can prevent the hotspot transformation from
happening properly, so the cursor's visible position won't match the
software's idea of where
On Tue, Nov 15, 2016 at 10:06:47AM -0800, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> >Sent: Tuesday, November 15, 2016 2:31 AM
> >To: Srivatsa, Anusha ; Mcgee, Jeff
> >
> >Cc: Ursulin, Tvrtko ;
> >intel-gfx@lists.fr
This commit adding all known marketing names for latest gen9 platforms.
Cc: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
README | 2 +-
man/intel.man | 2 +-
src/intel_module.c | 29 -
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a
On Tue, Nov 15, 2016 at 10:26:46AM +, Tvrtko Ursulin wrote:
>
> On 15/11/2016 00:39, Anusha Srivatsa wrote:
> >From: Peter Antoine
> >
> >The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> >is used for both cases.
> >
> >HuC loading needs to be before GuC loading. The WOPCM
I'm fine with libsoup as well, I'll check it out and probably move all
of the code over to using that instead.
On Tue, 2016-11-15 at 12:44 +0100, Tomeu Vizoso wrote:
> On 11 November 2016 at 18:53, Lyude Paul wrote:
> >
> > Alright, quick question: should we be going with your branch then
> > or
On Tue, Nov 15, 2016 at 03:46:42PM +, Chris Wilson wrote:
> Joonas complained that writing ww_mutex_lock(&resv->lock, ctx) was too
> intrusive compared to reservation_object_lock(resv, ctx);
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Joonas Lahtinen
> ---
> include/linux/rese
On Tue, Nov 15, 2016 at 07:23:26PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Tue, Nov 15, 2016 at 04:36:32PM +0200, Mika Kuoppala wrote:
> >> +static bool
> >> +hangcheck_engine_stall(struct intel_engine_cs *engine,
> >> + struct intel_engine_hangcheck *hc)
> >>
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/i915: Fix DP link rate math (rev3)
URL : https://patchwork.freedesktop.org/series/15305/
State : success
== Summary ==
Series 15305v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15305/revisions/3
Not validating the mode rate against max. link rate results in not pruning
invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not
support 4k@60Hz. But, we do not reject this mode.
So, make use of the helpers in intel_dp to validate mode data rate against
max. link data rate of a con
On Tue, 2016-11-15 at 20:59 +0200, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 09:35:30PM +, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> > > On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > > > Not validating the the mode
On Mon, Nov 14, 2016 at 09:35:30PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> > On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > > Not validating the the mode rate against link rate results not pruning
> > > invalid modes.
On Tue, 2016-11-15 at 11:30 +0200, Jani Nikula wrote:
> On Mon, 14 Nov 2016, Dhinakaran Pandiyan
> wrote:
> > We store DP link rates as link clock frequencies in kHz, just like all
> > other clock values. But, DP link rates in the DP Spec. are expressed in
> > Gbps/lane, which seems to have led t
== Series Details ==
Series: drm/i915/bxt: Broxton decoupled MMIO (rev5)
URL : https://patchwork.freedesktop.org/series/12028/
State : success
== Summary ==
Series 12028v5 drm/i915/bxt: Broxton decoupled MMIO
https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/5/mbox/
fi-bdw-555
>-Original Message-
>From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
>Sent: Tuesday, November 15, 2016 2:31 AM
>To: Srivatsa, Anusha ; Mcgee, Jeff
>
>Cc: Ursulin, Tvrtko ;
>intel-gfx@lists.freedesktop.org;
>Vivi, Rodrigo
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combi
== Series Details ==
Series: drm/i915: Be more careful to drop the GT wakeref (rev5)
URL : https://patchwork.freedesktop.org/series/15349/
State : warning
== Summary ==
Series 15349v5 drm/i915: Be more careful to drop the GT wakeref
https://patchwork.freedesktop.org/api/1.0/series/15349/revisi
Chris Wilson writes:
> On Tue, Nov 15, 2016 at 03:45:41PM -, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [1/6] drm/i915: Split up hangcheck phases
>> URL : https://patchwork.freedesktop.org/series/15351/
>> State : success
>>
>> == Summary ==
>>
>> Series
Chris Wilson writes:
> On Tue, Nov 15, 2016 at 04:36:32PM +0200, Mika Kuoppala wrote:
>> +static bool
>> +hangcheck_engine_stall(struct intel_engine_cs *engine,
>> + struct intel_engine_hangcheck *hc)
>> +{
>> +const unsigned long last_action = engine->hangcheck.action_times
== Series Details ==
Series: dma-buf: Provide wrappers for reservation's lock
URL : https://patchwork.freedesktop.org/series/15353/
State : success
== Summary ==
Series 15353v1 dma-buf: Provide wrappers for reservation's lock
https://patchwork.freedesktop.org/api/1.0/series/15353/revisions/1/m
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoids frequent software forcewake.
This certainly gives advantage over the forcewake as this new
mechanism “decouples” CPU cycles and allow them to complete even
when G
Chris Wilson writes:
> On Tue, Nov 15, 2016 at 04:36:35PM +0200, Mika Kuoppala wrote:
>> If we have a bad client submitting unfavourably across different
>> contexts, creating new ones, the per context scoring of badness
>> doesn't remove the root cause, the offending client.
>> To counter, keep
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: edd420eaffb3a618ddc8740683abc039ad97237f
commit: 6c4789edc55d5a0acefc85380d7a3f7c4f21c7cd [33/40] drm: Clean up
kerneldoc for struct drm_driver
reproduce: make htmldocs; make DOCBOOKS='' pdfdocs
All warnings (new ones prefixed
On Tue, Nov 15, 2016 at 03:45:41PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/6] drm/i915: Split up hangcheck phases
> URL : https://patchwork.freedesktop.org/series/15351/
> State : success
>
> == Summary ==
>
> Series 15351v1 Series without cover lette
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
== Series Details ==
Series: drm/i915/bxt: add bxt dsi gpio element support (rev3)
URL : https://patchwork.freedesktop.org/series/15338/
State : success
== Summary ==
Series 15338v3 drm/i915/bxt: add bxt dsi gpio element support
https://patchwork.freedesktop.org/api/1.0/series/15338/revisions/
On Tue, Nov 15, 2016 at 04:36:31PM +0200, Mika Kuoppala wrote:
> In order to simplify hangcheck state keeping, split hangcheck
> per engine loop in three phases: state load, action, state save.
>
> Add few more hangcheck actions to separate between seqno, head
> and subunit movements. This helps t
On Tue, Nov 15, 2016 at 04:36:32PM +0200, Mika Kuoppala wrote:
> +static bool
> +hangcheck_engine_stall(struct intel_engine_cs *engine,
> +struct intel_engine_hangcheck *hc)
> +{
> + const unsigned long last_action = engine->hangcheck.action_timestamp;
>
> - me
On Tue, Nov 15, 2016 at 04:36:33PM +0200, Mika Kuoppala wrote:
> As hangcheck score was removed, the active decay of score
> was removed also. This removed feature for hangcheck to detect
> if the gpu client was accidentally or maliciously causing intermittent
> hangs. Reinstate the scoring as a pe
On Tue, Nov 15, 2016 at 04:36:34PM +0200, Mika Kuoppala wrote:
> Now when driver has per context scoring of 'hanging badness'
> and also subsequent hangs during short windows are allowed,
> if there is progress made in between, it does not make sense
> to expose a ban timing window as a context par
On Tue, Nov 15, 2016 at 04:36:35PM +0200, Mika Kuoppala wrote:
> If we have a bad client submitting unfavourably across different
> contexts, creating new ones, the per context scoring of badness
> doesn't remove the root cause, the offending client.
> To counter, keep track of per client context b
== Series Details ==
Series: drm/i915: Be more careful to drop the GT wakeref (rev4)
URL : https://patchwork.freedesktop.org/series/15349/
State : success
== Summary ==
Series 15349v4 drm/i915: Be more careful to drop the GT wakeref
https://patchwork.freedesktop.org/api/1.0/series/15349/revisi
Joonas complained that writing ww_mutex_lock(&resv->lock, ctx) was too
intrusive compared to reservation_object_lock(resv, ctx);
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Joonas Lahtinen
---
include/linux/reservation.h | 34 ++
1 file changed, 34 insertio
== Series Details ==
Series: series starting with [1/6] drm/i915: Split up hangcheck phases
URL : https://patchwork.freedesktop.org/series/15351/
State : success
== Summary ==
Series 15351v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15351/revisions/1/mbox/
Request the GPIO by index through the consumer API. For now, use a quick
hack to store the already requested ones, simply because I have no idea
whether this actually works or not, and I have no way to test it.
Cc: Mika Kahola
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_
On Tue, Nov 15, 2016 at 04:38:19PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-14 at 08:53 +, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -53,6 +53,12 @@ i915_vma_retire(struct i915_gem_active *active,
> > if (--obj->active_count)
> > return;
> >
>
On Tue, 2016-11-15 at 14:25 +0100, Tomeu Vizoso wrote:
> On 15 November 2016 at 09:01, Daniel Vetter wrote:
> >
> > On Mon, Nov 14, 2016 at 06:59:16PM +0900, Gustavo Padovan wrote:
> > >
> > > From: Gustavo Padovan
> > >
> > > Signed-off-by: Gustavo Padovan
> > > ---
> > > tests/kms_atomic_t
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
On Tue, Nov 15, 2016 at 04:38:19PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-14 at 08:53 +, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -53,6 +53,12 @@ i915_vma_retire(struct i915_gem_active *active,
> > if (--obj->active_count)
> > return;
> >
>
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
On 15/11/2016 13:17, Praveen Paneri wrote:
Hi Chris,
On Tuesday 15 November 2016 03:37 PM, Chris Wilson wrote:
On Tue, Nov 15, 2016 at 09:36:34AM +, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
register
== Series Details ==
Series: drm/i915: Be more careful to drop the GT wakeref
URL : https://patchwork.freedesktop.org/series/15349/
State : success
== Summary ==
Series 15349v1 drm/i915: Be more careful to drop the GT wakeref
https://patchwork.freedesktop.org/api/1.0/series/15349/revisions/1/m
On ma, 2016-11-14 at 08:53 +, Chris Wilson wrote:
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -53,6 +53,12 @@ i915_vma_retire(struct i915_gem_active *active,
> if (--obj->active_count)
> return;
>
> + /* Prune the shared fence arrays iff completely idle (inc. external
In order to simplify hangcheck state keeping, split hangcheck
per engine loop in three phases: state load, action, state save.
Add few more hangcheck actions to separate between seqno, head
and subunit movements. This helps to gather all the hangcheck
actions under a single switch umbrella.
Cc: C
Now when driver has per context scoring of 'hanging badness'
and also subsequent hangs during short windows are allowed,
if there is progress made in between, it does not make sense
to expose a ban timing window as a context parameter anymore.
Let the scoring be the sole indicator for ban policy a
Bannable property, banned status, guilty and active counts are
properties of i915_gem_context. Make them so.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h| 27 ---
drivers/gpu/drm/i915/i915_gem.c| 25 +++
If we have a bad client submitting unfavourably across different
contexts, creating new ones, the per context scoring of badness
doesn't remove the root cause, the offending client.
To counter, keep track of per client context bans. Deny access if
client is responsible for more than 3 context bans
As hangcheck score was removed, the active decay of score
was removed also. This removed feature for hangcheck to detect
if the gpu client was accidentally or maliciously causing intermittent
hangs. Reinstate the scoring as a per context property, so that if
one context starts to act unfavourably,
Hangcheck state accumulation has gained more steps
along the years, like head movement and more recently the
subunit inactivity check. As the subunit sampling is only
done if the previous state check showed inactivity, we
have added more stages (and time) to reach a hang verdict.
Asymmetric engine
On Tue, Nov 15, 2016 at 10:44:29AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> > Would be great if everony could add
>
> everyone
>
> > $ make DOCBOOKS="" htmldocs
> >
> > to their build scripts to catch these. 0day should also report them,
> > n
On Tue, Nov 15, 2016 at 10:32:14AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:23PM +0100, Daniel Vetter wrote:
> > And shuffle the kernel-doc structure a bit since drm_crtc.[hc] now
> > only contains CRTC-related functions and structures.
> >
> > Signed-off-by: Daniel Vetter
> > d
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle w
On 15.11.2016 12:59, Tomeu Vizoso wrote:
> On 14 November 2016 at 19:24, Abdiel Janulgue
> wrote:
>> A lot of igt testcases need some GPU workload to make sure a race
>> window is big enough. Unfortunately having a fixed amount of
>> workload leads to spurious test failures or overtly long runti
Op 15-11-16 om 14:41 schreef Ville Syrjälä:
> On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote:
>> Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
>>> actually touching
On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote:
> Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> > actually touching the hardware, in which case we won't force a m
On 15 November 2016 at 09:01, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 06:59:16PM +0900, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Signed-off-by: Gustavo Padovan
>> ---
>> tests/kms_atomic_transition.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a
Hi Mika,
On 15 November 2016 at 12:38, Mika Kahola wrote:
> Testcase for plane visibility after atomic modesets. The idea of the test
> is the following:
>
> - draw a blue screen with high resolution
> - enable a yellow plane, visible, in lower-left corner
> - set a new lower resolution mode (
Hi
On 15.11.2016 10:45, Tomeu Vizoso wrote:
> Hi Abdiel,
>
> here running the whole of kms_busy causes all subtests after the first
> one to be skipped due to:
>
> Test requirement not met in function __real_main164, file
> ../../intel-gpu-tools/tests/kms_busy.c:195:
> Test requirement: gem_has_
== Series Details ==
Series: drm/i915/bxt: add bxt dsi gpio element support (rev2)
URL : https://patchwork.freedesktop.org/series/15338/
State : success
== Summary ==
Series 15338v2 drm/i915/bxt: add bxt dsi gpio element support
https://patchwork.freedesktop.org/api/1.0/series/15338/revisions/
Hi Chris,
On Tuesday 15 November 2016 03:37 PM, Chris Wilson wrote:
On Tue, Nov 15, 2016 at 09:36:34AM +, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single rea
On Tue, Nov 15, 2016 at 01:00:14PM +, Chris Wilson wrote:
> Reviewed-by: Chris Wilson
> -Chris
>
Thanks, pushed.
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Nov 15, 2016 at 02:34:42PM +0200, Petri Latvala wrote:
> Commit 721d8747e3a2 added sync() calls to igt_main and
> igt_simple_main, making self-tests fail to build. #including unistd.h
> in igt_core.h fixes that.
>
> Fixes: 721d8747e3a2 ("igt: Add a test for reordering execbufs")
> CC: Chri
Testcase for plane visibility after atomic modesets. The idea of the test
is the following:
- draw a blue screen with high resolution
- enable a yellow plane, visible, in lower-left corner
- set a new lower resolution mode (1024x768) that makes plane invisible
- check from debugfs 'i915_displa
Commit 721d8747e3a2 added sync() calls to igt_main and
igt_simple_main, making self-tests fail to build. #including unistd.h
in igt_core.h fixes that.
Fixes: 721d8747e3a2 ("igt: Add a test for reordering execbufs")
CC: Chris Wilson
Signed-off-by: Petri Latvala
---
lib/igt_core.h | 1 +
1 file c
On Tue, Nov 15, 2016 at 11:16:50AM +, Chris Wilson wrote:
> Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
> modification rather than proliferate it into all the callers of the
> insert (which may or may not in fact have to do the insertion).
>
> Signed-off-by: Chris Wi
Use a table similar to vlv to check for accepted gpio indexes. For now,
add all, but this list should be trimmed down. Use managed gpio request,
which will be automatically released when the driver is detached.
Cc: Mika Kahola
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_
Request the GPIO by index through the consumer API. For now, use a quick
hack to store the already requested ones, simply because I have no idea
whether this actually works or not, and I have no way to test it.
Cc: Mika Kahola
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_
On Tue, Nov 15, 2016 at 12:53:48PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:37:26AM +, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> > > kerneldoc expects the comment next to definitions, otherwise it can't
> > > pick up exported vs. in
On Tue, Nov 15, 2016 at 12:47:31PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:42:08AM +, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> > > b/drivers/gpu/drm/drm_dumb_buffers.c
> > > n
On Tue, Nov 15, 2016 at 10:37:26AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> > kerneldoc expects the comment next to definitions, otherwise it can't
> > pick up exported vs. internal stuff.
> >
> > This fixes a warning from the doc build done wit
On Tue, Nov 15, 2016 at 10:42:08AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> > b/drivers/gpu/drm/drm_dumb_buffers.c
> > new file mode 100644
> > index ..4b4364b61c8d
> > --- /dev/nul
== Series Details ==
Series: drm/i915: Invalidate the guc ggtt TLB upon insertion
URL : https://patchwork.freedesktop.org/series/15336/
State : success
== Summary ==
Series 15336v1 drm/i915: Invalidate the guc ggtt TLB upon insertion
https://patchwork.freedesktop.org/api/1.0/series/15336/revis
On 11 November 2016 at 18:53, Lyude Paul wrote:
> Alright, quick question: should we be going with your branch then or
> mine?
I'm not going to be able to work on this in the short term, so I think
it's up to you.
Wonder if there are more opinions regarding xmlrpc vs. libsoup. I
liked it mostly
On Tue, Nov 15, 2016 at 11:16:50AM +, Chris Wilson wrote:
> Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
> modification rather than proliferate it into all the callers of the
> insert (which may or may not in fact have to do the insertion).
>
> Signed-off-by: Chris Wi
Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
modification rather than proliferate it into all the callers of the
insert (which may or may not in fact have to do the insertion).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c
On 15 November 2016 at 11:59, Tomeu Vizoso wrote:
> On 14 November 2016 at 19:24, Abdiel Janulgue
> wrote:
>> A lot of igt testcases need some GPU workload to make sure a race
>> window is big enough. Unfortunately having a fixed amount of
>> workload leads to spurious test failures or overtly lo
On 11/15/2016 11:02 AM, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 09:47:31AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 15, 2016 at 04:29:04PM +0800, kbuild test robot wrote:
>>> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
>>> head: 35cf03508d8466ecc5199c9d609e74e85bec785b
On 15/11/2016 10:56, Praveen Paneri wrote:
Hi Tvrtko,
On Tuesday 15 November 2016 03:06 PM, Tvrtko Ursulin wrote:
On 15/11/2016 06:40, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoid
On 14 November 2016 at 19:24, Abdiel Janulgue
wrote:
> A lot of igt testcases need some GPU workload to make sure a race
> window is big enough. Unfortunately having a fixed amount of
> workload leads to spurious test failures or overtly long runtimes
> on some fast/slow platforms. This library co
On Tue, Nov 15, 2016 at 10:44:29AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> > Would be great if everony could add
>
> everyone
>
> > $ make DOCBOOKS="" htmldocs
> >
> > to their build scripts to catch these. 0day should also report them,
> > n
1 - 100 of 157 matches
Mail list logo
