On 2017.03.23 14:43:44 +0100, Frans Klaver wrote:
> On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote:
> > From: Colin Ian King
> >
> > info is being checked to see if it is a null pointer, however, vpgu is
> > dereferencing info before this check, leading to a potential null
> > pointer derefere
On 03/23/2017 02:26 PM, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling
On 2017.03.23 16:11:00 +0200, Joonas Lahtinen wrote:
> Dropping the irrelevant Cc's.
>
> On to, 2017-03-23 at 12:39 +, Chris Wilson wrote:
> > On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote:
> > >
> > > From: Colin Ian King
> > >
> > > info is being checked to see if it is a nul
GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.
v2: use context_status_change instead of exe
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scr
On Fri, Mar 24, 2017 at 12:52 AM, Robert Bragg wrote:
> On Thu, Mar 23, 2017 at 8:48 PM, Matthew Auld
> wrote:
>> On 23 March 2017 at 20:18, Robert Bragg wrote:
>>> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
>>> render metrics on Broadwell, Cherryview, Skylake and B
On Thu, Mar 23, 2017 at 8:48 PM, Matthew Auld
wrote:
> On 23 March 2017 at 20:18, Robert Bragg wrote:
>> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
>> render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
>> auto generated from an XML description of
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the Data Link N is greater than 0x8.
Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
value 20 bit instead of the maximum specification supported 24 bit value.
On 03/23/2017 03:57 PM, Chris Wilson wrote:
On Wed, Mar 22, 2017 at 10:39:46AM -0700, Oscar Mateo wrote:
Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.
v2:
- Null execbuf client outside guc_client_free (Daniele)
- Assert if things try to get a
Currently intel_dp_check_link_status() tries to retrain the link if
Clock recovery or Channel EQ for any of the lanes indicated by
intel_dp->lane_count is not set. However these values cached in intel_dp
structure can be stale if link training has failed for these values
during previous modeset. Or
Move the common "client->vaddr + client->proc_desc_offset" to its own
function, __get_process_desc() to match the newly established pattern.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
On Wed, Mar 22, 2017 at 10:39:46AM -0700, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
>
> v2:
> - Null execbuf client outside guc_client_free (Daniele)
> - Assert if things try to get allocated twice (Daniele/Joonas)
> - N
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> tests/kms_fbcon_fbt.c | 47 +++
> 1 file changed, 11 insertions(+), 36 deletions(-)
>
> diff --git a/tests/kms_fbcon_fbt.c b/
Reviewed-by: Rodrigo Vivi
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> tests/kms_frontbuffer_tracking.c | 47
>
> 1 file changed, 9 insertions(+), 38 deletions(-)
>
> dif
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Cc: Rodrigo Vivi
> Signed-off-by: Jim Bride
> ---
> tests/kms_psr_sink_crc.c | 53
> ++--
> 1 file changed, 11 insertions(+), 42 deletions(-)
>
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_
On Mon, 2017-02-13 at 15:43 -0800, Jim Bride wrote:
> Factor out some code that was replicated in three test utilities into
> some new IGT library functions so that we are checking PSR status in
> a consistent fashion across all of our PSR tests.
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-
On Thu, Mar 23, 2017 at 04:51:54PM +, Tvrtko Ursulin wrote:
>
> On 23/03/2017 13:48, Chris Wilson wrote:
> >We only need to care about the ordering of the clearing of the bit with
> >the uncached CSB read in order to correctly detect a new interrupt
> >before the read completes. The uncached r
On 03/23/2017 06:20 AM, Joonas Lahtinen wrote:
Merged this series except the HAX patch (also, reordered the S-o-b, R-b
and Cc lines to canonical form), so do rebase your work.
Regards, Joonas
Thanks!
On to, 2017-03-23 at 11:06 +, Patchwork wrote:
== Series Details ==
Series: Various
On Thu, Mar 23, 2017 at 09:27:08PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Share the code to compute the primary plane control register value
> between the i9xx and ilk codepaths as the differences are minimal.
> Actually there are no differences between g4x and ilk,
On Thu, Mar 23, 2017 at 09:27:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Pull the code to calculate the pre-SKL primary plane control register
> value into separate functions. Allows us to pre-compute it in the
> future.
>
> v2: Split the pre-ilk vs. ilk+ unificat
On 03/23/2017 03:44 PM, Chris Wilson wrote:
On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote:
Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered
intermittent hangs with the following information in the logs:
linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce,
Launch $EDITOR when extracting tags to curate the tags immediately. Once the
tags are proper, automatically add them before the first Signed-off-by line
to all patches in the range.
Signed-off-by: Sean Paul
---
dim | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git
Make extract-tags process tags from all messages in the supplied
mbox. This allows the user to tag multiple replies and extract
all tags at once.
Signed-off-by: Sean Paul
---
dim | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/dim b/dim
index 989674a..43ea794 100
On 23 March 2017 at 20:18, Robert Bragg wrote:
> Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
> render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
> auto generated from an XML description of metric sets, currently
> maintained in gputop, ref:
>
> h
On Thu, Mar 23, 2017 at 01:19:43PM -0500, Larry Finger wrote:
> Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered
> intermittent hangs with the following information in the logs:
>
> linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in
> plasmashell [1283], reason: Hang o
On 23 March 2017 at 20:18, Robert Bragg wrote:
> Assuming a uniform mask across all slices, this enables userspace to
> determine the specific sub slices enabled. This information is required,
> for example, to be able to analyse some OA counter reports where the
> counter configuration depends on
On 23 March 2017 at 20:18, Robert Bragg wrote:
> Enables userspace to determine the number of slices enabled and also
> know what specific slices are enabled. This information is required, for
> example, to be able to analyse some OA counter reports where the counter
> configuration depends on the
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous stat
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scr
Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices enabled. This information is required,
for example, to be able to analyse some OA counter reports where the
counter configuration depends on the HW sub slice configuration.
Signed-off-by: Robert
Enables userspace to determine the number of slices enabled and also
know what specific slices are enabled. This information is required, for
example, to be able to analyse some OA counter reports where the counter
configuration depends on the HW slice configuration.
Signed-off-by: Robert Bragg
-
Compared to the last Gen8+ OA series I've been investigating and debugging a
number of issues with the configuration of the Flexible EU counters whose state
is per-context:
* Removes assumption about the mmio registers having a contiguous range of
addresses which wasn't true.
* Ensures that newl
From: Ville Syrjälä
All the pre-SKL sprite planes compute the x/y/tile offsets in a
similar way. There are a couple of minor differences but the primary
planes have those as well. Thus i9xx_check_plane_surface()
already does what we need, so let's use it.
Signed-off-by: Ville Syrjälä
---
drive
From: Ville Syrjälä
Extract the primary plane surfae offset/x/y calculations for
pre-SKL platforms into a common function, and call it during the
atomic check phase to reduce the amount of stuff we have to do
during the commit phase. SKL is already doing this.
v2: Update the comment about the ro
From: Ville Syrjälä
Computing the plane control register value is branchy so moving it out
from the plane commit hook seems prudent. Let's pre-compute it during
the atomic check phase and store the result in the plane state.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/g
From: Ville Syrjälä
The effective difference between i9xx_update_primary_plane()
and ironlake_update_primary_plane() is only the HSW/BDW
DSPOFFSET special case. So bring that over into
i9xx_update_primary_plane() and eliminate the duplicated code.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris
From: Ville Syrjälä
Share the code to compute the primary plane control register value
between the i9xx and ilk codepaths as the differences are minimal.
Actually there are no differences between g4x and ilk, so the
current split doesn't really make any sense.
Cc: Chris Wilson
Signed-off-by: Vi
From: Ville Syrjälä
Here are the easy leftovers from the previous series. I left out
the more experimental parts (single lock/unlock, posting read
elimination) for now. I'll have to revisit those after we get
this stuff in.
This time I even took the precaution of testing this on one
of my gen2 m
From: Ville Syrjälä
Pull the code to calculate the pre-SKL primary plane control register
value into separate functions. Allows us to pre-compute it in the
future.
v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris)
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers
This change is pre-emptively aiming to avoid a potential cause of kernel
logging noise in case some condition were to result in us seeing invalid
OA reports.
The workaround for the OA unit's tail pointer race condition is what
avoids the primary know cause of invalid reports being seen and with
th
From: Ville Syrjälä
Literal tabs in printk() come out as garbage. Let's just use spaces.
Cc: Thomas Richter
Fixes: 14f1fa2d0c86 ("drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu
S6010")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/dvo_ns2501.c | 28 ++--
On Thu, 2017-03-23 at 10:59 -0700, Clint Taylor wrote:
> On 03/23/2017 10:23 AM, Jani Nikula wrote:
> > On Thu, 23 Mar 2017, Clint Taylor wrote:
> >> On 03/23/2017 05:30 AM, Jani Nikula wrote:
> >>> On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Sev
Hi Ville,
On 23-03-2017 18:14, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 17:42, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 16:43, S
Since kernel 4.11-rc1, my desktop (Plasma5/KDE) has encountered intermittent
hangs with the following information in the logs:
linux-4v1g.suse kernel: [drm] GPU HANG: ecode 7:0:0xf3ce, in plasmashell
[1283], reason: Hang on render ring, action: reset
linux-4v1g.suse kernel: [drm] GPU hangs
On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 23-03-2017 17:42, Ville Syrjälä wrote:
> > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:43, Sharma, Shashank wrote:
> >>> Regards
> >>>
> >>> Shashank
On 03/23/2017 10:23 AM, Jani Nikula wrote:
On Thu, 23 Mar 2017, Clint Taylor wrote:
On 03/23/2017 05:30 AM, Jani Nikula wrote:
On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the
Hi Ville,
On 23-03-2017 17:42, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:43, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 6:33 PM, Jose Abreu wrote:
Hi Shashank,
On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 23-03-2017 16:43, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/23/2017 6:33 PM, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:08, Sharma, Shashank wrote:
> >>> Regard
On Thu, 23 Mar 2017, Clint Taylor wrote:
> On 03/23/2017 05:30 AM, Jani Nikula wrote:
>> On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
>>> From: Clint Taylor
>>>
>>> Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
>>> signal if the Data Link N is greater than
Hi Shashank,
On 23-03-2017 16:43, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 6:33 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 16:08, Sharma, Shashank wrote:
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:52 PM, Jose Abreu wrote:
> > Hi Ville,
> >
> >
> > On 23-03-2017 15:36, Ville Syrjälä wrote:
> >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> >>> HDMI 1.4b support
On 23/03/2017 13:48, Chris Wilson wrote:
We only need to care about the ordering of the clearing of the bit with
the uncached CSB read in order to correctly detect a new interrupt
before the read completes. The uncached read itself acts as a full
memory barrier, so we do not to enforce another i
On Thu, Feb 23, 2017 at 3:35 PM, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 04:36:31PM +, Robert Bragg wrote:
>> Since the exponent for periodic OA counter sampling is maintained in a
>> per-context register while we want to treat it as if it were global
>> state we need to be able to safel
Regards
Shashank
On 3/23/2017 6:33 PM, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 16:08, Sharma, Shashank wrote:
Regards
Shashank
On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 16:08, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:57 PM, Jose Abreu wrote:
>> Hi Ville,
>>
>>
>> On 23-03-2017 15:45, Ville Syrjälä wrote:
>>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-
Regards
Shashank
On 3/23/2017 5:28 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
1-64).
Regards
Shashank
On 3/23/2017 5:52 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:36, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI
On 03/23/2017 05:30 AM, Jani Nikula wrote:
On Thu, 23 Mar 2017, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
signal if the Data Link N is greater than 0x8.
Patch detects when 1 lane 5.4 GHz signal is being
Regards
Shashank
On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 15:14, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861
== Series Details ==
Series: series starting with [v4,1/2] drm/edid: Complete CEA modedb(VIC 1-107)
URL : https://patchwork.freedesktop.org/series/21772/
State : success
== Summary ==
Series 21772v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21772/revisions/1/
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 23-03-2017 15:14, Shashank Sharma wrote:
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
>>> For any other mode, the VIC fi
Hi Ville,
On 23-03-2017 15:36, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
>> For any other mode, the VIC filed in AVI infoframes should be 0.
>> HDMI 2.0 sinks, support vide
Hi Dave,
drm-misc-fixes-2017-03-23:
One fbdev regression fix from Michel
Cheers, Daniel
The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c:
Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-mi
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 23-03-2017 15:14, Shashank Sharma wrote:
> > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> > For any other mode, the VIC filed in AVI infoframes should be 0.
> > HDMI 2.0 sinks, sup
== Series Details ==
Series: drm/i915: Check we have an wake device before flushing GTT writes (rev2)
URL : https://patchwork.freedesktop.org/series/20899/
State : success
== Summary ==
Series 20899v2 drm/i915: Check we have an wake device before flushing GTT writes
https://patchwork.freedeskt
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to
Hi Shashank,
On 23-03-2017 15:14, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
> On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
>> wrote:
>>>
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
>>> 1-64).
>>> For any other mode, the VIC filed in A
Regards
Shashank
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
We can assume that if the device is asleep then all pending GTT writes
will have been posted, and so we can defer the flush from
i915_gem_object_flush_gtt_write_domain()
[ 1957.462568] WARNING: CPU: 0 PID: 6132 at
drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915]
[ 1957.4625
On Thu, Mar 23, 2017 at 03:23:28PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 04:22:38PM +0200, Joonas Lahtinen wrote:
> > + Daniel for the rsvd2
>
> I'd go with a shadow struct definition which matches the uapi one exactly,
> except for having a proper name and type for this ... Or we
On Thu, Mar 23, 2017 at 12:06:22PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Ack on the entire pile.
-Daniel
> ---
> dim | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/dim b/dim
> index 7b6275e7796f..989674ab7a91 100755
> --- a/dim
> +++ b/dim
>
On Thu, Mar 23, 2017 at 12:06:16PM +0200, Jani Nikula wrote:
> Oops, the comment told us to watch out for this.
>
> Fixes: 56e53a49e28f ("dim: declare and assign separately")
I just hacked around this with a || true :-)
Ack.
-Daniel
> Signed-off-by: Jani Nikula
> ---
> dim | 5 +
> 1 file
Hi Ville,
On 21 March 2017 at 18:12, wrote:
> Another iteration of the i915 CCS support. Main change is lifting the
> fb dimensions hsub/vsub alignment restrictions from the core. Without that
> userspace would have to align the fb size be a multiple of 8x16 pixels
> which isn't something they a
On Wed, Mar 22, 2017 at 04:22:38PM +0200, Joonas Lahtinen wrote:
> + Daniel for the rsvd2
I'd go with a shadow struct definition which matches the uapi one exactly,
except for having a proper name and type for this ... Or we do the
anynomous union thing again.
-Daniel
>
> On ke, 2017-03-22 at 09
Dropping the irrelevant Cc's.
On to, 2017-03-23 at 12:39 +, Chris Wilson wrote:
> On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote:
> >
> > From: Colin Ian King
> >
> > info is being checked to see if it is a null pointer, however, vpgu is
> > dereferencing info before this check,
== Series Details ==
Series: drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
URL : https://patchwork.freedesktop.org/series/21767/
State : failure
== Summary ==
Series 21767v1 drm/i915/execlists: Relax the locked clear_bit(IRQ_EXECLIST)
https://patchwork.freedesktop.org/api/1.0/se
On Fri, Mar 17, 2017 at 11:17:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The plane updates are still taking far too long, at least with
> heavy kernel debug knobs turned on. Using kms_atomic_transitions
> I'm currently seeing numbers as high as 170 usec on my VLV.
== Series Details ==
Series: series starting with [01/15] drm/i915: Copy user requested buffers into
the error state (rev4)
URL : https://patchwork.freedesktop.org/series/21377/
State : failure
== Summary ==
drivers/gpu/drm/i915/i915_gem_execbuffer.c:1891:1: error: expected expression
before
> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Thursday, March 23, 2017 5:52 PM
> To: Dong, Chuanxiao; intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt n
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Chris Wilson
> Sent: Thursday, March 23, 2017 5:43 PM
> To: Joonas Lahtinen
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> Dong, Chuanxiao
> Subjec
We only need to care about the ordering of the clearing of the bit with
the uncached CSB read in order to correctly detect a new interrupt
before the read completes. The uncached read itself acts as a full
memory barrier, so we do not to enforce another in the form of a locked
clear_bit.
Signed-of
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, March 23, 2017 5:38 PM
> To: Dong, Chuanxiao; intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/scheduler: add gvt
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the s
Merged this series except the HAX patch (also, reordered the S-o-b, R-b
and Cc lines to canonical form), so do rebase your work.
Regards, Joonas
On to, 2017-03-23 at 11:06 +, Patchwork wrote:
> == Series Details ==
>
> Series: Various improvements around the GuC topic
> URL : https://patc
== Series Details ==
Series: drm/i915/kvmgt: avoid dereferencing a potentially null info pointer
URL : https://patchwork.freedesktop.org/series/21762/
State : warning
== Summary ==
Series 21762v1 drm/i915/kvmgt: avoid dereferencing a potentially null info
pointer
https://patchwork.freedesktop
On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c
> b/drivers/gpu/drm/armada/armada_overlay.c
> index 34cb73d0db77..b54fd8cbd3a6 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.
We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.
Note we have only been using a single bit to track flushing since
commit cc889e0f6ce6a63c62db17d702ecfed
On Wed, 22 Mar 2017, "Sharma, Shashank" wrote:
> Thanks for this patch, Jani.
>
> Reviewed-by: Shashank Sharma
And pushed to drm-misc-next, thanks for the review.
BR,
Jani.
>
>
> Regards
> Shashank
> On 3/22/2017 4:33 PM, Jani Nikula wrote:
>> Fix sparse warning:
>>
>> drivers/gpu/drm/drm_scd
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit
v3: Moved force_test_atomic flag set to 'test_plane_position()'
v4: Fix typo in subject field
Signed-off-by: Mika Kahola
---
tests/
On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote:
> On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
> >> Hi, Daniel,
> >>
> >> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
> >>> On Thu, Mar 23, 2017 at 08:28:32AM +01
Add TEST_ONLY flag to test atomic transition display commits without
actual real-life commit.
v2: use flag to force atomic commit with TEST_ONLY flag
v3: Rebase
Signed-off-by: Mika Kahola
---
tests/kms_atomic_transition.c | 72 +++
1 file changed, 59 inse
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
Signed-off-by: Mika Kahola
---
tests/kms_cursor_legacy.c | 230 --
1 file changed, 204 insertions(+), 26 deletions(-)
diff --git a/tests/kms_cursor_legacy.c b/tests
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit
v3: Moved force_test_atomic flag set to 'test_plane_position()'
Signed-off-by: Mika Kahola
---
tests/kms_plane_multiple.c | 48
Add TEST_ONLY flag to test atomic modesetting commits without
actual real-life commit.
v2: Use flag to indicate to test with TEST_ONLY flag with atomic
commit
v3: Moved force_test_atomic flag set to 'test_plane_position()'
Signed-off-by: Mika Kahola
---
tests/kms_plane_multiple.c | 48
Add TEST_ONLY flag to test atomic scaling without
actually committing the changes.
v2: Create subtests with TEST_ONLY flag and one without
v3: Rename subtest 'force-atomic-test' as 'with-atomic-test'
Signed-off-by: Mika Kahola
---
tests/kms_plane_scaling.c | 28
1 f
Add an option to force atomic commits to do commits with TEST_ONLY flag
first before doing the actual commit.
v2: Clear force_test_atomic flag if atomic commit with TEST_ONLY
flag fails (Maarten)
Signed-off-by: Mika Kahola
---
lib/igt_kms.c | 22 +-
lib/igt_kms.h | 1 +
1 - 100 of 161 matches
Mail list logo
