On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
> >> Paolo, for this case, do you think it's feasible we pick them through
> >> drm/i915 merge path? As currently initial KVMGT patch sets require these
> >> exported symbols, that's why I ask how we should handle this dependency.
> >
> > Then it's
On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> The previous spec version said "double Ytile planes minimum lines",
> and I interpreted this as referring to what the spec calls "Y tile
> minimum", but in fact it was referring to what the spec calls "Minimum
> Scanlines for Y tile".
On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote:
> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
> partitioning for multi-screen cases"), and the other was added by
> 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen
> cases"). I'm confused and I
On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> > The function's behaviour was changed in 90844f00049e, without changing
> > its signature, causing people to keep using it the old way without
> > realising they were
On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> The function's behaviour was changed in 90844f00049e, without changing
> its signature, causing people to keep using it the old way without
> realising they were now leaking memory.
> Rob Clark also noticed it was also allocating GFP
On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> As I told people in [1] we really should not be confusing enum plane
> as a per-pipe plane identifier. Looks like that happened nonetheless, so
> let's fix it up by splitting the two into two
== Series Details ==
Series: drm: move allocation out of drm_get_format_name() (rev3)
URL : https://patchwork.freedesktop.org/series/14873/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/dvo_ns2501.o
CC [M] drivers/gpu/drm/i915/dvo_sil164.o
CC [M] drivers/gpu/drm/i915/dvo_t
The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.
Instead of having to
t;drm: Track drm_mm allocators and show leaks on shutdown")
I hate used the drm-misc tree from next-20161108 for today.
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Series Details ==
Series: drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
URL : https://patchwork.freedesktop.org/series/14990/
State : success
== Summary ==
Series 14990v1 drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
https://patchwork.freedesktop.org/ap
The previous spec version said "double Ytile planes minimum lines",
and I interpreted this as referring to what the spec calls "Y tile
minimum", but in fact it was referring to what the spec calls "Minimum
Scanlines for Y tile". I noticed that Mahesh Kumar had a different
interpretation, so I sent
== Series Details ==
Series: drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()
URL : https://patchwork.freedesktop.org/series/14984/
State : success
== Summary ==
Series 14984v1 drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()
https://patchwork.freedesktop.org/api/1.
== Series Details ==
Series: drm/i915: Add a per-pipe plane identifier enum (rev3)
URL : https://patchwork.freedesktop.org/series/14978/
State : warning
== Summary ==
Series 14978v3 drm/i915: Add a per-pipe plane identifier enum
https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/
One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
partitioning for multi-screen cases"), and the other was added by
01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen
cases"). I'm confused and I'll let the maintainers find out what went
wrong here.
Cc: Jani Nikul
On Tue, Nov 08, 2016 at 06:04:15PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > > Now, I know you're working on getting rid of this entirely for i915, but
> > > what about that MSM driver? Will we continue to need it there, is
> > > anybody actua
From: Ville Syrjälä
Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.
v2: Convert assert_sprites_disabled() over as well
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 58
From: Ville Syrjälä
Nuke skl_wm_plane_id() and just use the new intel_plane->id.
v2: Convert skl_write_plane_wm() as well
Cc: Matt Roper
Cc: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Lyude
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > Now, I know you're working on getting rid of this entirely for i915, but
> > what about that MSM driver? Will we continue to need it there, is
> > anybody actually maintaining that thing?
>
> Rob Clark is, and since he's a one-man
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > You're talking about:
> >
> > lkml.kernel.org/r/20161007154351.gl3...@twins.programming.kicks-ass.net
> >
> > ? I got no feedback from you DRM guys on that so I kinda forgot about
> > that in the hope we'd not have to do this at
On Tue, Nov 08, 2016 at 04:04:23PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:16PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Use intel_plane->id to derive the VLV/CHV sprite register offsets
> > instead of abusing plane->plane which is really mean
On Tue, Nov 08, 2016 at 02:49:05PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote:
> > The newly added assert_kernel_context_is_current introduces a warning
> > when built with W=1:
> >
> > drivers/gpu/drm/i915/i915_gem.c: In function
> > ‘assert_kernel
On Mon, Nov 07, 2016 at 05:18:21PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> This is current fixes for GVT-g device model part. Most notable is to
> fix a regression from e95433c73a11 ("drm/i915: Rearrange
> i915_wait_request() accounting with callers") which has stopped our
> testing.
>
> As for th
On Tue, Nov 08, 2016 at 02:24:48PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > FIXME: Add owner of second tree to To:
> > >Add author(s)/SOB of
On Tue, Nov 08, 2016 at 04:47:16PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use intel_plane->id to derive the VLV/CHV sprite register offsets
> instead of abusing plane->plane which is really meant to for
> primary planes only.
>
> Signed-off-by: Ville Syrjälä
> ---
On Tue, Nov 08, 2016 at 03:16:13PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Spin until breadcrumb threads are complete
> URL : https://patchwork.freedesktop.org/series/14977/
> State : success
>
> == Summary ==
>
> Series 14977v1 drm/i915: Spin until breadcrumb thre
== Series Details ==
Series: drm/i915: Add a per-pipe plane identifier enum
URL : https://patchwork.freedesktop.org/series/14978/
State : warning
== Summary ==
Series 14978v1 drm/i915: Add a per-pipe plane identifier enum
https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/1/mbox/
On Tue, Nov 08, 2016 at 03:26:31PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > As I told people in [1] we really should not be confusing enum plane
> > as a per-pipe plane identifier. Looks like that h
On Tue, Nov 08, 2016 at 03:23:14PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
> > capable plane feeding the LVDS port by default.
On Tue, Nov 08, 2016 at 03:30:33PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:19PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > With plane->plane now purely reserved for the primary planes, let's
> > not even populate it for cursors and sprites. Let'
On Tue, Nov 08, 2016 at 04:47:19PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> With plane->plane now purely reserved for the primary planes, let's
> not even populate it for cursors and sprites. Let's switch the type
> to enum plane as well since it's no longer being abu
On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> As I told people in [1] we really should not be confusing enum plane
> as a per-pipe plane identifier. Looks like that happened nonetheless, so
> let's fix it up by splitting the two into two
On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
> capable plane feeding the LVDS port by default. We have the logic for
> the plane swapping duplicated in many places. Le
Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > On Mon, 07 Nov 2016, Martin Steigerwald wrote:
> > > It is also the same kind of corruptions as shown in
> > >
> > > [Bug 177701] warning in intel_dp_aux_tr
== Series Details ==
Series: drm/i915: Spin until breadcrumb threads are complete
URL : https://patchwork.freedesktop.org/series/14977/
State : success
== Summary ==
Series 14977v1 drm/i915: Spin until breadcrumb threads are complete
https://patchwork.freedesktop.org/api/1.0/series/14977/revis
Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald wrote:
> > It is also the same kind of corruptions as shown in
> >
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> >
> > Just compar
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 93ce75fa3dba8781c5c042bd7a61d438662ed73c
commit: 5705670d0463423337c82d00877989e7df8b169d [1/14] drm: Track drm_mm
allocators and show leaks on shutdown
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu
From: Ville Syrjälä
On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
capable plane feeding the LVDS port by default. We have the logic for
the plane swapping duplicated in many places. Let's remove a bit of the
duplication by having the crtc look up the thing from the primary
From: Ville Syrjälä
Nuke skl_wm_plane_id() and just use the new intel_plane->id.
Cc: Matt Roper
Cc: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Lyude
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 156 +---
1 file changed, 64 insertions(+)
From: Ville Syrjälä
Now we've rename the local plane id variable as 'plane_id' everywhere
except the pre-SKL primary plane code. Let's do the rename there as well
so that we'll free up the name 'plane' for use with struct intel_plane*.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/inte
From: Ville Syrjälä
This series aims to clean up the mess we have with intel_plane->plane
by adding a new intel_plane->id thing. Afterwards the two are clearly
separated so that intel_plane->id is the per-pipe plane identifier,
and intel_plane->plane is the legacy primary plane identifier
(ie. sa
From: Ville Syrjälä
Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 58 -
drivers/gpu/drm/i915/
== Series Details ==
Series: drm/i915: avoid harmless empty-body warning
URL : https://patchwork.freedesktop.org/series/14973/
State : failure
== Summary ==
Series 14973v1 drm/i915: avoid harmless empty-body warning
https://patchwork.freedesktop.org/api/1.0/series/14973/revisions/1/mbox/
Test
On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote:
> The newly added assert_kernel_context_is_current introduces a warning
> when built with W=1:
>
> drivers/gpu/drm/i915/i915_gem.c: In function
> ‘assert_kernel_context_is_current’:
> drivers/gpu/drm/i915/i915_gem.c:4417:63: error: su
From: Ville Syrjälä
With plane->plane now purely reserved for the primary planes, let's
not even populate it for cursors and sprites. Let's switch the type
to enum plane as well since it's no longer being abused for anything
else.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dis
From: Ville Syrjälä
Let's try not to abuse plane->plane for sprites on VLV/CHV and instead
use plane->id. Since out watermark structures aren't entirely plane type
agnostic (for now) and start indexing sprites from 0 we'll add a small
helper to convert between the two bases.
Signed-off-by: Vill
From: Ville Syrjälä
Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane
code with intel_plane->id.
This should make the SKL "primary" and "sprite" code virtually
identical, so the next logical step would likely be dropping one
of the copies.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Add a mask of which planes are available for each pipe. This doesn't
quite work for old platforms with dynamic plane<->pipe assignment, but
as we don't support that sort of stuff (yet) we can get away with it.
The main use I have for this is the for_each_plane_id_on_crtc() ma
From: Ville Syrjälä
As I told people in [1] we really should not be confusing enum plane
as a per-pipe plane identifier. Looks like that happened nonetheless, so
let's fix it up by splitting the two into two enums.
We'll also want something we just directly pass to various register
offset macros
When we need to reset the global seqno on wraparound, we have to wait
until the current rbtrees are drained (or otherwise the next waiter will
be out of sequence). The current mechanism to kick and spin until
complete, may exit too early as it would break if the target thread was
currently running.
On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > FIXME: Add owner of second tree to To:
> >Add author(s)/SOB of conflicting commits.
> >
> > Today's linux-next merge of the tip tree got a
On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote:
> This is a hack and not needed. Use the right mask by checking
> intel_state->modeset. This works for watermark sanitization too.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_pm.c | 38 +++-
On Tue, Nov 08, 2016 at 01:55:40PM +0100, Maarten Lankhorst wrote:
> All of this state should be updated as soon as possible. It shouldn't be
> done later because then future updates may not depend on it.
>
> Changes since v1:
> - Move the modeset update to before drm_atomic_state_get. (Ville)
>
On Tue, Nov 08, 2016 at 01:55:38PM +0100, Maarten Lankhorst wrote:
> drm_select_eld requires mode_config.mutex and connection_mutex
> because it looks at the connector list and at the legacy encoders.
>
> This is not required, because when we call audio_codec_enable we know
> which connector it wa
The newly added assert_kernel_context_is_current introduces a warning
when built with W=1:
drivers/gpu/drm/i915/i915_gem.c: In function ‘assert_kernel_context_is_current’:
drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty
body in an ‘else’ statement [-Werror=empty-body]
On Mon, Nov 07, 2016 at 09:20:05PM +, Chris Wilson wrote:
> On Mon, Nov 07, 2016 at 10:20:57PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The code to determine the primary plane offset for gen2/3 looks
> > different than the code for gen4+, but in fact it's do
This is a testcase with multiple planes. The idea here is the following
- draw a uniform frame with blue color
- grab crc for reference
- put planes randomly on top with the same blue color
- punch holes with black color into the primary framebuffer
- ideally the planes should cover these hol
== Series Details ==
Series: Skylake watermark fixes and nonblocking modeset.
URL : https://patchwork.freedesktop.org/series/14966/
State : success
== Summary ==
Series 14966v1 Skylake watermark fixes and nonblocking modeset.
https://patchwork.freedesktop.org/api/1.0/series/14966/revisions/1/m
On Tue, Nov 08, 2016 at 11:42:38AM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote:
> > On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote:
> > > - i915_gem_object_flush_cpu_write_domain(obj);
> > > + if (obj->cache_dirty || obj->base.write_domai
On Tue, 2016-11-08 at 14:14 +0100, Maarten Lankhorst wrote:
> Op 08-11-16 om 12:54 schreef Mika Kahola:
> >
> > This is a testcase with multiple planes. The idea here is the
> > following
> >
> > - draw a uniform frame with blue color
> > - grab crc for reference
> > - put planes randomly on t
== Series Details ==
Series: Enable i915 perf stream for Haswell OA unit (rev2)
URL : https://patchwork.freedesktop.org/series/14935/
State : failure
== Summary ==
Series 14935v2 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/14935/revisions/2/mbox
Op 08-11-16 om 12:54 schreef Mika Kahola:
> This is a testcase with multiple planes. The idea here is the following
>
> - draw a uniform frame with blue color
> - grab crc for reference
> - put planes randomly on top with the same blue color
> - punch holes with black color into the primary fra
The only user was i915, which is now gone.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
Acked-by: Dave Airlie #irc
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_edid.h | 1 -
2 files changed, 27 deletions
This is the last bit required for making nonblocking modesets work
correctly. The state in intel_crtc->hw_ddb is not updated until
somewhere in atomic commit, while the previous crtc state should be
accurate if the ddb hasn't changed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/int
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.
This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.
This also removes having to look at crtc->c
This member is only used in skl_update_crtcs now. It's easy to remove it
by keeping track of which ddb entries in an array, and update them after
we update the crtc. This removes the last bits of SKL-style watermarks
kept outside of crtc_state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/dr
Allow the driver to write watermarks during atomic evasion.
This will make it possible to write the watermarks in a cleaner
way on gen9+.
intel_atomic_state is not used here yet, but will be used when
we program all watermarks as a separate step during evasion.
This also writes linetime all the t
This is a hack and not needed. Use the right mask by checking
intel_state->modeset. This works for watermark sanitization too.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff
The watermark updates for SKL style watermarks are no longer done
in the plane callbacks, but are now called in a separate watermark
update function that's called during the same vblank evasion,
before the plane updates.
This also gets rid of the global skl_results, which was required for
keeping
This is the last connector still looking at crtc->config. Fix this.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_hdmi.c | 48 +--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i91
This gets rid of a warning that the connectors are used without locking
when doing a nonblocking modeset.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ee8b6db0b425..759b1fdbb009 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
All of this state should be updated as soon as possible. It shouldn't be
done later because then future updates may not depend on it.
Changes since v1:
- Move the modeset update to before drm_atomic_state_get. (Ville)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 1
These are the remaining watermark fixes required before nonblocking
modeset can be enabled, plus the patches required to enable
nonblocking modeset support in i915.
Maarten Lankhorst (11):
drm/i915: Add a atomic evasion step to watermark programming, v3.
drm/i915/gen9+: Program watermarks as a
This v2 patch bumps the command parser version so it can be referenced in
corresponding i-g-t gem_exec_parse changes.
--- >8 ---
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mes
On Mon, Nov 07, 2016 at 01:59:45PM +, Chris Wilson wrote:
> The scheduler needs to know the dependencies of each request for the
> lifetime of the request, as it may choose to reschedule the requests at
> any time and must ensure the dependency tree is not broken. This is in
> additional to usi
On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote:
>
>
> On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta
> wrote:
> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling frequency is now configurable via a
> > dev.i915.oa_max_sample_rate sysc
This is a testcase with multiple planes. The idea here is the following
- draw a uniform frame with blue color
- grab crc for reference
- put planes randomly on top with the same blue color
- punch holes with black color into the primary framebuffer
- ideally the planes should cover these hol
By the way, series was tested on CI with no regressions.
- Abdiel
On 11/07/2016 09:48 AM, 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
On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta wrote:
> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling frequency is now configurable via a
> > dev.i915.oa_max_sample_rate sysctl parameter.
> >
> > Following the precedent set by perf's similar
> > kernel.perf_even
On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote:
> On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote:
> > - i915_gem_object_flush_cpu_write_domain(obj);
> > + if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> > + i915_gem_clflush_object(
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 3835b46e5535d9ad534776bc93670db097682556
commit: 5705670d0463423337c82d00877989e7df8b169d [1/13] drm: Track drm_mm
allocators and show leaks on shutdown
config: i386-randconfig-i1-201645 (attached as .config)
compiler: gcc-4.8
On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote:
> Currently we only clflush the scanout if it is in the CPU domain. Also
> flush if we have a pending CPU clflush. We also want to treat the
> dirtyfb path similar, and flush any pending writes there as well.
>
> Signed-off-by: Chris Wi
On Fri, Nov 04, 2016 at 03:03:59PM +, Chris Wilson wrote:
> Recently a patch ran successfully through BAT that broke 64bit
> relocations on a couple of machines. Oops. So lets add a very fast set
> of tests to check basic relocation handling.
>
> Signed-off-by: Chris Wilson
> ---
This comm
On Mon, Nov 07, 2016 at 06:16:00PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-07 at 12:10 +, Chris Wilson wrote:
> > On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote:
> > >
> > > On su, 2016-11-06 at 12:59 +, Chris Wilson wrote:
> > > >
> > > > We always flush the chips
On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> th
On Mon, Nov 07, 2016 at 09:28:58PM +, Chris Wilson wrote:
> On Mon, Nov 07, 2016 at 10:20:53PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
> > offset in the plane check hook for SKL+") we've
On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> FIXME: Add owner of second tree to To:
>Add author(s)/SOB of conflicting commits.
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_gem_shrinker.c
>
> between co
On ti, 2016-11-08 at 07:46 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Remove two sloppy inline functions from .h (rev2)
> URL : https://patchwork.freedesktop.org/series/14931/
> State : success
>
Merged the patch, thanks for the review.
Regards, Joonas
--
Joonas Lah
On Mon, Nov 07, 2016 at 10:26:59PM +, Robert Bragg wrote:
> The command parser no longer whitelists or does anything special for the
> OACONTROL register which is now considered owned by i915-perf.
>
> As a follow up the plan is to at least check that attempting to write to
> OACONTROL from us
On Mon, Nov 07, 2016 at 07:38:25PM +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> > On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
> >> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> >> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >> >
> >> > drm: make
On Mon, Nov 07, 2016 at 07:05:14PM -0500, Lyude wrote:
> The default autoresume delay is about 5 seconds. It's possible on a
> system that's not very fast this might not be a long enough time, since
> an asynchronous hotplug event we scheduled on the chamelium that was
> intended to happen during s
On Mon, Nov 07, 2016 at 07:05:15PM -0500, Lyude wrote:
> Since we're going to be using lists for keeping track of EDIDs we've
> allocated on the chamelium, add some generic list helpers from the
> wayland project.
We are a little more familiar with the kernel naming convention.
-Chris
--
Chris W
On Sat, Oct 29, 2016 at 07:42:14PM +0100, Chris Wilson wrote:
> A frequent issue that arises on shutdown is the drm_mm range manager
> complaining of a leak. To aide debugging those, drm can now track the
> allocation callsite and print those for the leaks.
>
> Signed-off-by: Chris Wilson
Makes
On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote:
> In order to support deferred scheduling, we need to differentiate
> between when the request is ready to run (i.e. the submit fence is
> signaled) and when the request is actually run (a new execute fence).
> This is typically split between th
On Thu, Nov 03, 2016 at 06:22:05PM +0200, Ville Syrjälä wrote:
> This thing could use a commit message I think. Could at least lay out
> the basic rules on the foo->state/foo_state vs. old_state/new_state
> replacements. Might help someone understand it who doesn't know so much
> about the current
On Thu, Nov 03, 2016 at 05:32:42PM +0200, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 02:37:04PM +0200, Maarten Lankhorst wrote:
> > This kills another dereference of connector->state. connector_mask
> > holds all unchanged connectors at least and any changed connectors
> > are already in state
On Tue, Nov 08, 2016 at 09:43:21AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote:
> > @@ -56,6 +61,24 @@ int i915_gem_timeline_init(struct drm_i915_private *i915,
> > return 0;
> > }
> >
> > +int i915_gem_timeline_init(struct drm_i915_private *i915,
> >
On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
> >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> >> replace the old for_each_xxx_in_stat
On Thu, Nov 03, 2016 at 02:52:00PM -0400, Rob Clark wrote:
> On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> >
> > I moved the main bits to be the first diffs, shouldn't affect anything
> > when applying the patch, but I wanted to ask:
> > I don'
99 matches
Mail list logo