== Series Details ==
Series: drm/atomic: Acquire connection_mutex lock in
drm_helper_probe_single_connector_modes, v2.
URL : https://patchwork.freedesktop.org/series/22423/
State : success
== Summary ==
Series 22423v1 drm/atomic: Acquire connection_mutex lock in
drm_helper_probe_single_conne
On Tue, Apr 04, 2017 at 10:27:57AM +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Nikula, Jani
> > Sent: Tuesday, April 4, 2017 3:48 PM
> > To: Ander Conselvan De Oliveira ; intel-
> > g...@lists.freedesktop.org
> > Cc: Chauhan, Madhav ; Ville Syrjälä
> >
> > Subject: Re: [
> -Original Message-
> From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> Sent: Tuesday, April 4, 2017 4:13 PM
> To: Chauhan, Madhav ; Nikula, Jani
> ; intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, April 4, 2017 5:09 PM
> To: Chauhan, Madhav
> Cc: Nikula, Jani ; Ander Conselvan De Oliveira
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99%
When doing a full atomic modeset, kernel should fail if the flag
DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of
Intel-GPU-Tools. The test procedure is the following:
- Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET flag.
Kernel should reject this request.
If the engine is continually completing nops, we can saturate the
signaler and keep it working indefinitely. This angers the NMI watchdog!
A good example is to disable semaphores on snb and run igt/gem_exec_nop -
the parallel, multi-engine workloads are more than sufficient to hog the
CPU, prevent
== Series Details ==
Series: drm/i915: Apply a cond_resched() to the saturated signaler (rev2)
URL : https://patchwork.freedesktop.org/series/22418/
State : success
== Summary ==
Series 22418v2 drm/i915: Apply a cond_resched() to the saturated signaler
https://patchwork.freedesktop.org/api/1.0
Hey,
Op 04-04-17 om 13:59 schreef Mika Kahola:
> When doing a full atomic modeset, kernel should fail if the flag
> DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of
> Intel-GPU-Tools. The test procedure is the following:
>
> - Try to do atomic commit without DRM_MODE_ATOMIC
On Tue, Apr 04, 2017 at 10:57:15AM +0100, Tvrtko Ursulin wrote:
>
> On 03/04/2017 11:51, Chris Wilson wrote:
> >If the signal to park arrives before we sleep, then we need to check
> >kthread_should_park() before sleeping to avoid missing the signal.
> >Otherwise, if the signal arrives whilst we a
On 04/04/2017 13:05, Chris Wilson wrote:
If the engine is continually completing nops, we can saturate the
signaler and keep it working indefinitely. This angers the NMI watchdog!
A good example is to disable semaphores on snb and run igt/gem_exec_nop -
the parallel, multi-engine workloads are
On Tue, Apr 04, 2017 at 12:24:15PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Apply a cond_resched() to the saturated signaler (rev2)
> URL : https://patchwork.freedesktop.org/series/22418/
> State : success
>
> == Summary ==
>
> Series 22418v2 drm/i915: Apply a cond_
On Tue, Apr 04, 2017 at 11:53:42AM +, Chauhan, Madhav wrote:
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, April 4, 2017 5:09 PM
> > To: Chauhan, Madhav
> > Cc: Nikula, Jani ; Ander Conselvan De Oliveira
> > ; intel-gfx@lists.f
On Mon, Apr 03, 2017 at 11:49:16AM +0300, Joonas Lahtinen wrote:
> On pe, 2017-03-31 at 15:10 +0100, Chris Wilson wrote:
> > Rebrand the current (pointer | bits) pack/unpack utility macros as
> > explicit bit twiddling for PAGE_SIZE so that we can use the more
> > flexible underlying macros for dif
ptr_unpack_bits() is a function-like macro, as such it is meant to be
replaceable by a function. In this case, we should be passing in the
out-param as a pointer.
Bizarrely this does affect code generation:
function old new delta
i915_gem_object_pin_map
add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new delta
execlists_submit_ports 262 471+209
port_assign.isra - 136+136
capture 63
Rebrand the current (pointer | bits) pack/unpack utility macros as
explicit bit twiddling for PAGE_SIZE so that we can use the more
flexible underlying macros for different bits.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers
On Fri, Mar 31, 2017 at 03:10:33PM +0100, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index a82a0807f64d..51497653c830 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
This reverts commit ea49c9acf2db7082f0406bb3a570cc6bad37082b.
mode_config.mutex was originally added to fix WARNs in connector
functions, but now that atomic nonblocking modeset support is
included, we will likely never hold any any lock at all.
The WARN mentioned in commit bbf35e9defb9a6d1 ("drm
There is no need to acquire all locks here,
doing a commit after forcing a modeset on the affected crtc
is enough. Any other locks needed will be acquired as needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pipe_crc.c | 17 ++---
1 file changed, 14 insertions(+
On 31/03/2017 13:58, Patchwork wrote:
== Series Details ==
Series: drm/i915/huc: Simplify intel_huc_init_hw()
URL : https://patchwork.freedesktop.org/series/22280/
State : success
== Summary ==
Series 22280v1 drm/i915/huc: Simplify intel_huc_init_hw()
https://patchwork.freedesktop.org/api/1
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, April 4, 2017 6:26 PM
> To: Chauhan, Madhav
> Cc: Nikula, Jani ; Ander Conselvan De Oliveira
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99%
Almost all other GuC fw definitions are using GUC|guc prefix.
While around, in get_core_family() change explicit WARN into MISSING_CASE
as it looks more appropriate, since GuC support capability we are controlling
by intel_device_info.has_guc flag.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahti
On 04/04/2017 14:38, Michal Wajdeczko wrote:
Almost all other GuC fw definitions are using GUC|guc prefix.
While around, in get_core_family() change explicit WARN into MISSING_CASE
as it looks more appropriate, since GuC support capability we are controlling
by intel_device_info.has_guc flag.
S
It's rather obnoxious to exit in the middle of something just because
you haven't updated the script. Only issue a warning.
Signed-off-by: Jani Nikula
---
dim | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dim b/dim
index 33d5fd3c0303..8671bcb84845 100755
--- a/dim
+
The functions have been added kind of in the middle at some point. Clean
it up.
Signed-off-by: Jani Nikula
---
dim | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/dim b/dim
index a76e4e4d3f09..45dc07cd0426 100755
--- a/dim
+++ b/dim
@@ -114,16 +114,6 @@
Reserve the middle part of the script for function and alias definitions
only.
Signed-off-by: Jani Nikula
---
dim | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/dim b/dim
index 8671bcb84845..a76e4e4d3f09 100755
--- a/dim
+++ b/dim
@@ -204,6 +204,10 @@ if [ "$su
Similar to git. Don't allow override of internal commands though.
Signed-off-by: Jani Nikula
---
dim | 6 ++
1 file changed, 6 insertions(+)
diff --git a/dim b/dim
index 45dc07cd0426..85da1542087e 100755
--- a/dim
+++ b/dim
@@ -1907,6 +1907,12 @@ fi
# look up the function by the subcommand
== Series Details ==
Series: series starting with [1/3] drm/i915: Make ptr_unpack_bits() more
function-like
URL : https://patchwork.freedesktop.org/series/22432/
State : success
== Summary ==
Series 22432v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22432/rev
== Series Details ==
Series: Revert "drm/i915: Lock mode_config.mutex in intel_display_resume."
URL : https://patchwork.freedesktop.org/series/22434/
State : success
== Summary ==
Series 22434v1 Revert "drm/i915: Lock mode_config.mutex in
intel_display_resume."
https://patchwork.freedesktop.o
== Series Details ==
Series: drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa
URL : https://patchwork.freedesktop.org/series/22435/
State : success
== Summary ==
Series 22435v1 drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa
https://patchwork.freedesktop.org/api/1.0/se
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.
References: https://bugs.freedesktop.org/show_bug.
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> To match the drm_ioctl.c we already have.
>
> v2: Remove spurious space (Ville).
>
> Cc: Ville Syrjälä
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> - remove docs for internal func, doesn't add value
> - add short overview snippet instead explaining that drivers don't
> have to bother themselves with reg/unreg concerns
> - drop the ttm comment about drmP.h, drmP.h is disappearing ...
>
> Signed-
== Series Details ==
Series: drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions
URL : https://patchwork.freedesktop.org/series/22436/
State : success
== Summary ==
Series 22436v1 drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions
https://patchwork.freedesktop.org/api/1.0/series/224
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> Also unify/merge with the existing stuff.
>
> I was a bit torn where to put this, but in the end I decided to put
> all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
> have a bit a split with the other uapi related stuff used internal
On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote:
> The major scaling bottleneck in execbuffer is the processing of the
> execobjects. Creating an auxiliary list is inefficient when compared to
> using the execobject array we already have allocated.
>
> Reservation is then split into phases. A
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> There's really no reason for anything more:
> - Calling this while the crtc vblank stuff isn't set up is a driver
> bug. Those places arlready DRM_ERROR.
s/arlready/already/
> - Calling this when the crtc is off is either a driver bug (callin
s/calli
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> It's overkill to have a flag parameter which is essentially used just
> as a boolean. This takes care of core + adjusting drivers.
>
> Adjusting the scanout position callback is a bit harder, since radeon
> also supplies it's own driver-private flags
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> This is going to be a bit too much, but good to have at least a small
> note about where this should all head towards.
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_drv.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git
On Tue, Apr 04, 2017 at 04:59:02PM +0300, Jani Nikula wrote:
> Similar to git. Don't allow override of internal commands though.
git did this, and then went to a slightly different version because
git doesn't complete to a space due to the various git-foo commands
in path. Imo the right way to do
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> If we restrict this helper to only kms drivers (which is the case) we
> can look up the correct mode easily ourselves. But it's a bit tricky:
>
> - All legacy drivers look at crtc->hwmode. But that is update already
is updated ?
> at the beginning o
== Series Details ==
Series: drm/i915: Only report a wakeup if the waiter was truly asleep
URL : https://patchwork.freedesktop.org/series/22445/
State : success
== Summary ==
Series 22445v1 drm/i915: Only report a wakeup if the waiter was truly asleep
https://patchwork.freedesktop.org/api/1.0/
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> - We can drop the different return value flags, the only caller only
> cares about whether the scanout position is valid or not. Also, it's
> entirely undefined what "accurate" means, if we'd really care we
> should probably wire the max_error th
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> Drive-by cleanup.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_probe_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> inde
On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> Just drive-by, but we have gsoc running so better to update it now.
>
> Great news is that two entries can be removed because essentially all
> done.
>
> v2: Keep a bunch of the todos, Gabriel is working on them.
>
> Cc: Gabriel Krisman Bertazi
> S
On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> In the previous patch we've implemented hwmode tracking a la i915 for
> the vblank timestamp calculations. But that was just the basic
> semantics, i915 has some nice sanity checks to make sure we keep
> getting this right. Move them over too.
>
> Cc:
Op 29-03-17 om 16:21 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> We're clearing the legacy_cursor_update flag before calling
> drm_atomic_helper_setup_commit() which means the helper will
> wait for the flip to complete before cleaning up the framebuffers.
> That's not what we
On Tue, Apr 04, 2017 at 05:50:10PM +0200, Maarten Lankhorst wrote:
> Op 29-03-17 om 16:21 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > We're clearing the legacy_cursor_update flag before calling
> > drm_atomic_helper_setup_commit() which means the helper will
> > wait for
== Series Details ==
Series: drm/i915: Enable atomic for VLV/CHV
URL : https://patchwork.freedesktop.org/series/20634/
State : success
== Summary ==
Series 20634v1 drm/i915: Enable atomic for VLV/CHV
https://patchwork.freedesktop.org/api/1.0/series/20634/revisions/1/mbox/
Test gem_busy:
Noticed this while I was looking at some debug output,
[drm:intel_hdmi_compute_config [i915]] picking bpc to 12 for HDMI output
[drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 36 for HDMI
I believe the second line should be pipe *bpp*
Signed-off-by: Dhinakaran Pandiyan
---
drivers/
== Series Details ==
Series: drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'
URL : https://patchwork.freedesktop.org/series/22462/
State : success
== Summary ==
Series 22462v1 drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'
https://patchwork.freedesktop.org/api/1.0/series/22462/revisions/1/mbox/
On Tue, Apr 04, 2017 at 04:46:06PM +0200, Neil Armstrong wrote:
> On 04/04/2017 11:52 AM, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> >
> > v2: Remove spurious space (Ville).
> >
> > Cc: Ville Syrjälä
> > Reviewed-by: Ville Syrjälä
> > Signed-off-by: Daniel Vetter
> >
On Tue, Apr 04, 2017 at 05:12:59PM +0200, Neil Armstrong wrote:
> On 04/04/2017 11:53 AM, Daniel Vetter wrote:
> > Drive-by cleanup.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a
Looks good to me.
Reviewed-by:
Manasi
On Tue, Mar 28, 2017 at 05:59:01PM +0300, Jani Nikula wrote:
> I can't think of a real world bug this could cause now, but this will be
> required in follow-up work. While at it, change the parameter order to
> be slightly more sensible.
>
> Cc: Manasi Nav
On Wed, Mar 29, 2017 at 10:17:41AM +0300, Jani Nikula wrote:
> On Tue, 28 Mar 2017, Manasi Navare wrote:
> > Won't it make more sense to squash this patch with Patch 01 in this series?
> > When i was reading Patch 1, I almost was going to comment about
> > handling the case where we dont find the
On Tue, Mar 28, 2017 at 05:59:03PM +0300, Jani Nikula wrote:
> Rename the function, move it at the top, and reuse in
> intel_dp_link_rate_index(). If there was a reason in the past to use
> reverse search order here, there isn't now.
>
> The names may be slightly confusing now, but intel_dp_link_r
From: "Pandiyan, Dhinakaran"
drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi fo
From: "Pandiyan, Dhinakaran"
Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
Similarly, link bw is released during ->atomic_che
From: "Pandiyan, Dhinakaran"
Having an ->atomic_release callback is useful to release shared resources
that get allocated in compute_config(). This function is expected to be
called in the atomic_check() phase before new resources are acquired.
v5: Return an int (Maarten)
v4: Document that the f
From: "Pandiyan, Dhinakaran"
Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the
shared link bandwidth for a primary link directly connected to the GPU. For
atomic modesetting drivers, checking if there is suffici
From: "Pandiyan, Dhinakaran"
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and cle
== Series Details ==
Series: Adding driver-private objects to atomic state (rev6)
URL : https://patchwork.freedesktop.org/series/22177/
State : failure
== Summary ==
CC drivers/usb/host/xhci-dbg.o
CC net/ipv4/udp_diag.o
CC net/ipv4/tcp_cubic.o
CC net/ipv4/xfrm4_poli
To enable 64K pages we need to set the intermediate-page-size(IPS) bit
of the pde, therefore a page table is said to be either operating in 64K
or 4K mode. To accommodate this vm placement restriction we introduce a
color for pages and corresponding color_adjust callback.
Signed-off-by: Matthew Au
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 33 ++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 ++-
drivers/gpu/drm/i915/
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 70 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ddc3db345b7
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c| 5 +
drivers/gpu/drm/i915/i915_gem_object.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4ca88f2539c0..cbf97f4bbb72 100644
--- a/drivers/
Same as before, folding in review comments. Notably we now hook in transparent
huge pages through by shmem, and *attempt* to deal with all the fun which that
brings. Again should be considered very much RFC.
So far I have only gone as far as testing 2M pages on my BDW machine.
Thanks,
Matt
Matth
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 53 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
2 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index fb822c0bd973
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9dc12955f55
As hinted by the comment and from actually testing 2M pages on a BDW
machine with the GTT cache enabled, we are definitely going to need keep
it disabled.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --gi
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 0c8350f709da..0989af4a17e4 100644
--- a/drivers/gpu/drm/i915/i915_gem
v2: s/roundup/round_up
s/rounddown/round_down
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 123 ++
drivers/gpu/drm/i915/selftests/mock_gtt.c | 3 +
2 files changed, 89 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/dr
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_evict.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 0c9c51be0f6a..817acff2fb6c 100644
--- a/drivers/gpu/drm/i915/i91
Export color_differs so that we can use it elsewhere.
v2: better naming
Signed-off-by: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_vma.c | 11 ---
drivers/gpu/drm/i915/i915_vma.h | 6 ++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/d
v2:
- move out pde/pdpe bit definitions until later
- tidyup the page size definitions, use BIT
- introduce helper for detecting invalid page sizes
Signed-off-by: Matthew Auld
Cc: Mika Kuoppala
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_g
Mock test filling an address space with 4K and 64K objects, in the hope
of exercising the page color adjust fun.
v2: s/roundup/round_up
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 68 +++
1 file changed, 68 insertions(+)
diff --git a/
Rid the code of any mm.color_adjust assumptions to allow adding another
flavour of coloring.
v2: better naming
Signed-off-by: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i9
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 117 ++--
1 file changed, 111 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 8c0b4dc9de3d..78
In its current form huge-pages through shmemfs are controlled at the
super-block level, and are currently disabled by default, so to enable
huge-pages for a shmem backed gem object we would need to re-mount the
fs with the huge= argument, but for drm the mount is not user visible,
so good luck with
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_debugfs.c | 38 ++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d689e511744e..e8a50481c703 100644
--- a/d
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem.c | 187 +---
drivers/gpu/drm/i915/i915_vma.c | 8 ++
3 files changed, 166 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/dr
On Tue, 2017-04-04 at 20:36 +, Patchwork wrote:
> == Series Details ==
>
> Series: Adding driver-private objects to atomic state (rev6)
> URL : https://patchwork.freedesktop.org/series/22177/
> State : failure
>
I guess the in-reply-to confused CI. Here's the result for the same
series se
Hi all,
After merging the drm-misc tree, today's linux-next build
(arm_multi_v7_defconfig) produced this warning:
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning:
'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function]
static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_form
Reviewed-by:
Manasi
On Tue, Mar 28, 2017 at 05:59:04PM +0300, Jani Nikula wrote:
> We need the source rates array so often that it makes sense to set it
> once at init. This reduces function calls when we need the rates, making
> the code easier to follow.
>
> Cc: Manasi Navare
> Cc: Ville Sy
I agree with disentangling the fallback rate limiting
from sink rates and instead just limiting the common_rates array
based on max link rate.
Reviewed-by:
Manasi
On Tue, Mar 28, 2017 at 05:59:05PM +0300, Jani Nikula wrote:
> There is some conflation related to sink rates, making this change m
Reviewed-by:
Manasi
On Tue, Mar 28, 2017 at 05:59:07PM +0300, Jani Nikula wrote:
> Now that source rates are static and sink rates are updated whenever
> DPCD is updated, we can do and cache the intersection of them whenever
> sink rates are updated. This reduces code complexity, as we don't hav
The commit message looks good now.
Reviewed-by:
Manasi
On Wed, Mar 29, 2017 at 12:23:10PM +0300, Jani Nikula wrote:
> In link training fallback, we're trying to find a rate that we know is
> in a sorted array of common link rates. We don't need to limit the array
> using the max rate. For test
On Wed, Mar 29, 2017 at 10:22:32AM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Manasi Navare wrote:
> > Why not squash this with patch 08/14? and call it cleanup for obtaining the
> > rate index using intel_dp_rate_index()
> > Just a thought..
>
> Again, usually too big patches are the probl
Yes this is a good optimization.
Manasi
On Tue, Mar 28, 2017 at 05:59:13PM +0300, Jani Nikula wrote:
> This is what we have the readb and writeb variants for. Do some minor
> return value and variable cleanup while at it.
>
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Stolen memory is in RMRR and has identity mapping in iommu, so
gt could access stolen memory in host OS. While RMRR isn't supported
by kvm, both EPT and guest iommu domain lack of maaping for stolen memory,
so both vcpu and gt couldn't access stolen memory in guest.
commit "04a68a3 drm/i915/gvt: D
GVT requires force-single-submission and notification when i915
using execlist submit, and these should be extended to GuC when
i915 using GuC submit. Below two patches are used to implement this
Chuanxiao Dong (2):
drm/i915/scheduler: add gvt force-single-submission for guc
drm/i915/scheduler
GVT needs single submission and cannot allow merge. So when GuC submitting
a GVT request, the next one should be submitted to guc later until the
previous one is completed. This is following the usage when using execlist
mode submission.
v2: make force-single-submission specific to gvt (Chris)
v3:
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.
Cc: xiao.zh...@intel.com
Cc: kevin.t...@inte
== Series Details ==
Series: drm/i915: Enhanced disable access to stolen memory as a guest (rev4)
URL : https://patchwork.freedesktop.org/series/21818/
State : success
== Summary ==
Series 21818v4 drm/i915: Enhanced disable access to stolen memory as a guest
https://patchwork.freedesktop.org/a
Sorry, I don't find them in bspec. With our testing, SKL/APL works and KBL
failed.
The commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 mentioned should not do
testing on KBL DP audio.
We found the issue in the testing for Ubuntu latest release 17.04. (Almost
upstream)
But really I don't know
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Tuesday, April 4, 2017 6:55 PM
>To: Wang, Quanxian ; intel-
>g...@lists.freedesktop.org
>Cc: Yang, Libin
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value
>manually for KBL.
>
>On Sat,
Hi Quanxian,
>-Original Message-
>From: Wang, Quanxian
>Sent: Wednesday, April 5, 2017 10:21 AM
>To: Jani Nikula ; intel-gfx@lists.freedesktop.org
>Cc: Yang, Libin
>Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value
>manually for KBL.
>
>Sorry, I don't find them in bspe
Hi, Libin
We don't have 4K resolution monitor. We will double check others resolutions.
-Original Message-
From: Yang, Libin
Sent: Wednesday, April 5, 2017 10:22 AM
To: Jani Nikula ; Wang, Quanxian
; intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/scheduler: add gvt
force-single-submission for guc
URL : https://patchwork.freedesktop.org/series/22482/
State : success
== Summary ==
Series 22482v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/serie
During S3/S4 suspend, i915 sends HOST2GUC with ENTER_S_STATE action
for suspending GuC. GuC stops scheduling at this point. i915 is
currently doing explicit GPU reset during suspend ensuring GEM is idle.
Suspend GuC prior to triggering GPU Reset to ensure GuC stays idle too.
Cc: Jeff McGee
Cc: Da
1 - 100 of 147 matches
Mail list logo
