Op 28-03-17 om 09:01 schreef Daniel Vetter:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 68cded453882..43dbad62786e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12463,6 +12463,11 @@
On Thu, 2017-03-30 at 09:36 +0200, Maarten Lankhorst wrote:
> Op 28-03-17 om 09:01 schreef Daniel Vetter:
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 68cded453882..43dbad62786e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
On Wed, Mar 29, 2017 at 10:47:34PM +0200, Julia Lawall wrote:
> The kfree on line 926 would only be a problem for the references to e on
> lines 933 and 937 if the return value of drm_event_reserve_init can be
> -EDEADLK.
It cannot, but would indeed be prudent to reset to NULL, like we do at the
t
On Thu, Mar 30, 2017 at 07:48:45AM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-03-30 at 09:36 +0200, Maarten Lankhorst wrote:
> > Op 28-03-17 om 09:01 schreef Daniel Vetter:
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > inde
Sanity check the edid block generation capabilities.
Cc: Petri Latvala
Signed-off-by: Abdiel Janulgue
---
lib/tests/Makefile.sources | 1 +
lib/tests/igt_hdmi_inject.c | 96 +
2 files changed, 97 insertions(+)
create mode 100644 lib/tests/igt_hdmi_
Original author: Marius Vlad. Includes fixes below.
v5: Convert unit tests to lib selftest.
v4: Add a unit test to make sure synthetic EDID blocks generated by
IGT is valid (suggested by Petri).
v3: Make audio injection work.
Cc: Petri Latvala
Signed-off-by: Abdiel Janulgue
---
tests/Mak
Having added the wait upon each engine to idle into the central
i915_gem_wait_for_idle(), we can remove the now redundant wait from
reset_all_global_seqno(). This has the advantage of removing the late
detection of an error (an engine still busy) which left the seqno reset
only partially complete (
We can merge the pair of loops over the engines and their timelines into
a single loop, making it easier to read and more consistent with the
commentary.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
Make i915_gem_wait_for_idle() be a little heavier in order to try and
guarantee that the GPU is indeed idle (by checking each engine
individually is idle, i.e. all writes are complete and the rings
stopped) after waiting for in-flight requests to be completed.
v2: And return the final error.
v3: B
With CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=n we see the following
link error in the i915 driver:
drivers/built-in.o: In function 'intel_backlight_device_register':
(.text+0x2a921d): undefined reference to 'backlight_device_register'
Fix this by removing the condition on ACPI from the ap
As we declare an engine as wedged, we mark all of its active requests as
in error. However, we don't want to mark successfully completed requests
as in error, which requires us to retire those requests first.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
1 file cha
Chris Wilson writes:
> On Wed, Mar 29, 2017 at 10:36:16PM +0100, Chris Wilson wrote:
>> Some GPUs may have writes inflight much longer than expected, so before
>> declaring the GPU is idle, try to flush them using any
>> engine->irq_seqno_barrier() if available. By allowing them to be
>> flushed,
If the driver is wedged, HW state may be very inconsistent and
report that it is still busy, even though we have stopped using it. This
can lead to a double *ERROR* rather than a graceful cleanup after
wedging.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 4 +---
driv
On Thu, Mar 30, 2017 at 11:29:40AM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Wed, Mar 29, 2017 at 10:36:16PM +0100, Chris Wilson wrote:
> >> Some GPUs may have writes inflight much longer than expected, so before
> >> declaring the GPU is idle, try to flush them using any
> >> e
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.
v4: Document that the function is conditionally cal
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
Changes in this version:
Included the 5 left over patches. Patches 1 and 5 have changed, so
I have removed Maarten's R-B for patch 5.
1/5: Added NULL checks
5/5: Fixed vcpi slot accounting when atomic_release() is called multiple
times within an atomic_check()
This series
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
Since commit 1233e2db199d ("drm/i915: Move object backing storage
manipulation to its own locking"), i915_gem_object_put_pages() and
specifically the i915_gem_gtt_finish_pages() may be called from outside
of the struct_mutex and so we can no longer pass I915_WAIT_LOCKED to
i915_gem_wait_for_idle.
On Wed, Mar 29, 2017 at 03:11:26PM -0700, Ben Widawsky wrote:
> On 17-03-29 23:17:13, Ville Syrjälä wrote:
> >On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:
> >> This was based on a patch originally by Kristian. It has been modified
> >> pretty heavily to use the new callbacks from t
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Wait for all engines to be idle
as part of i915_gem_wait_for_idle()
URL : https://patchwork.freedesktop.org/series/22173/
State : success
== Summary ==
Series 22173v1 Series without cover letter
https://patchwork.freedesktop
== Series Details ==
Series: drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE
URL : https://patchwork.freedesktop.org/series/22174/
State : warning
== Summary ==
Series 22174v1 drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE
https://patchwork.freedesktop.org/api/
Handlers are currently the only blocker to compile the kernel with gcc 7
and KASAN+use-after-scope enabled:
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 43760
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c:2402:1: error: the
Stolen memroy is in RMRR and have identity mapping in iommu, so
gt could access stolen memory in host OS. While RMRR isn't supported
in kvm, both EPT and guest iommu domain lack of maaping for stolen memory,
so both vcpu an gt couldn't access stolen memroy in guest.
commit "04a68a3 drm/i915/gvt: D
On to, 2017-03-30 at 09:53 +0100, Chris Wilson wrote:
> Since commit 1233e2db199d ("drm/i915: Move object backing storage
> manipulation to its own locking"), i915_gem_object_put_pages() and
> specifically the i915_gem_gtt_finish_pages() may be called from outside
> of the struct_mutex and so we ca
Hi,
Here's GVT-g update for 4.12. Major things are vGPU scheduler
QoS support from Gao Ping, initial KBL support on E3 server from
Han Xu.
Note that QoS series depends on "drm/i915/gvt: adjust mem size for low
resolution type",
which is also a fix for 4.11, so to minimize backmerge effort also
On Thu, Mar 30, 2017 at 01:02:52PM +0300, Joonas Lahtinen wrote:
> On to, 2017-03-30 at 09:53 +0100, Chris Wilson wrote:
> > Since commit 1233e2db199d ("drm/i915: Move object backing storage
> > manipulation to its own locking"), i915_gem_object_put_pages() and
> > specifically the i915_gem_gtt_fin
Pushing this, thanks for the patch and review.
On ke, 2017-03-29 at 00:12 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/guc: Take enable_guc_loading check out of GEM core code
> URL : https://patchwork.freedesktop.org/series/22041/
> State : success
>
> == Summary ==
>
>
On ke, 2017-03-29 at 10:10 +0100, Chris Wilson wrote:
> Scatter a few cond_resched() in between phases of the drm_mm selftests
> to try and prevent us incurring the wrath of the NMI watchdog.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Hi Thierry,
On 29.03.2017 16:43, Thierry Reding wrote:
> From: Thierry Reding
>
> This set of patches adds support for deferring FB helper setup, which is
> useful to obtain a sane configuration even when no outputs are available
> during probe.
>
> One example is HDMI, where fbdev will currently
== Series Details ==
Series: drm/i915: Do request retirement before marking engines as wedged
URL : https://patchwork.freedesktop.org/series/22175/
State : failure
== Summary ==
Series 22175v1 drm/i915: Do request retirement before marking engines as wedged
https://patchwork.freedesktop.org/ap
Op 30-03-17 om 10:42 schreef Dhinakaran Pandiyan:
> 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 acq
== Series Details ==
Series: drm/i915: Suppress busy status for engines if wedged
URL : https://patchwork.freedesktop.org/series/22176/
State : success
== Summary ==
Series 22176v1 drm/i915: Suppress busy status for engines if wedged
https://patchwork.freedesktop.org/api/1.0/series/22176/revis
Michał Winiarski pointed out that the debugging infrastructure (such as
trace_dma_fence_release) likes to pretty print the timeline name, long
after we have freed the timeline. Our timelines currently live as part of
the GTT (due to the strict ordering we current use through each) which
belong to t
== Series Details ==
Series: Adding driver-private objects to atomic state
URL : https://patchwork.freedesktop.org/series/22177/
State : warning
== Summary ==
Series 22177v1 Adding driver-private objects to atomic state
https://patchwork.freedesktop.org/api/1.0/series/22177/revisions/1/mbox/
On Thu, Mar 30, 2017 at 12:16:14PM +0100, Chris Wilson wrote:
> Michał Winiarski pointed out that the debugging infrastructure (such as
> trace_dma_fence_release) likes to pretty print the timeline name, long
> after we have freed the timeline. Our timelines currently live as part of
> the GTT (due
Some of the DRM_NOTE messages are just using "uC" without specifying
which uc they are related to. We can be more user friendly.
v2: moved to the header (Joonas)
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/inte
This is yet another spin of uc/guc/huc code cleanup.
Michal Wajdeczko (5):
drm/i915/uc: Move intel_uc_fw_status_repr() to intel_uc.h
drm/i915/uc: Add intel_uc_fw_type_repr()
drm/i915/uc: Add intel_uc_fw_fini()
drm/i915/huc: Remove unused intel_huc_fini()
drm/i915/uc: Move fw path check t
Cleanups of uc firmware structs from GuC and Huc are the same for both.
Move common code to the helper function to avoid duplication.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
Reviewed-by: Arkadiusz Hiler
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/int
This function is no longer used. Its functionality is covered
by intel_uc_fini_fw().
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
Reviewed-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_huc.c | 18 --
drivers/gpu/drm/i915/intel_uc.h | 1 -
2 fi
There is no reason to separately check for valid fw path before
we try to fetch it. Let the fetch function take care of this.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
Reviewed-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_uc.c | 10 +-
1 file change
The file fits better. Also use "" for invalid case.
v2: move directly to .h (Joonas)
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_guc_loader.c | 16
drivers/gpu/drm/i915/intel_uc.h
On Thu, Mar 30, 2017 at 11:21:12AM +, Michal Wajdeczko wrote:
> Some of the DRM_NOTE messages are just using "uC" without specifying
> which uc they are related to. We can be more user friendly.
>
> v2: moved to the header (Joonas)
>
> Signed-off-by: Michal Wajdeczko
> Cc: Arkadiusz Hiler
>
On to, 2017-03-30 at 12:19 +0100, Chris Wilson wrote:
> On Thu, Mar 30, 2017 at 12:16:14PM +0100, Chris Wilson wrote:
> >
> > Michał Winiarski pointed out that the debugging infrastructure (such as
> > trace_dma_fence_release) likes to pretty print the timeline name, long
> > after we have freed t
== Series Details ==
Series: drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
URL : https://patchwork.freedesktop.org/series/22179/
State : success
== Summary ==
Series 22179v1 drm/i915: Ironlake do_idle_maps w/a may be called w/o
struct_mutex
https://patchwork.freedesktop.o
On Thu, Mar 30, 2017 at 12:27:45PM +0100, Chris Wilson wrote:
> On Thu, Mar 30, 2017 at 11:21:12AM +, Michal Wajdeczko wrote:
> > Some of the DRM_NOTE messages are just using "uC" without specifying
> > which uc they are related to. We can be more user friendly.
> >
> > v2: moved to the header
On Wed, Mar 29, 2017 at 09:16:36PM +, Pandiyan, Dhinakaran wrote:
> On Wed, 2017-03-29 at 11:50 +0300, Ville Syrjälä wrote:
> > On Tue, Mar 07, 2017 at 04:12:52PM -0800, Dhinakaran Pandiyan wrote:
> > > According to BSpec, "The CD clock frequency must be at least twice the
> > > frequency of th
On Thu, Mar 30, 2017 at 11:33:59AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
> URL : https://patchwork.freedesktop.org/series/22179/
> State : success
>
> == Summary ==
>
> Series 22179v1 drm/i915: Ironlake do_
== Series Details ==
Series: drm/i915: disable KASAN for handlers
URL : https://patchwork.freedesktop.org/series/22184/
State : success
== Summary ==
Series 22184v1 drm/i915: disable KASAN for handlers
https://patchwork.freedesktop.org/api/1.0/series/22184/revisions/1/mbox/
Test gem_exec_susp
On Thu, Mar 30, 2017 at 12:16:14PM +0100, Chris Wilson wrote:
> Michał Winiarski pointed out that the debugging infrastructure (such as
> trace_dma_fence_release) likes to pretty print the timeline name, long
> after we have freed the timeline. Our timelines currently live as part of
> the GTT (due
On to, 2017-03-30 at 09:37 +0100, Chris Wilson wrote:
> If the driver is wedged, HW state may be very inconsistent and
> report that it is still busy, even though we have stopped using it. This
> can lead to a double *ERROR* rather than a graceful cleanup after
> wedging.
>
> Signed-off-by: Chris
On Wed, Mar 22, 2017 at 09:56:12PM +0100, 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
> at the beginn
On to, 2017-03-30 at 09:28 +0100, Chris Wilson wrote:
> As we declare an engine as wedged, we mark all of its active requests as
> in error. However, we don't want to mark successfully completed requests
> as in error, which requires us to retire those requests first.
>
> Signed-off-by: Chris Wils
On Thu, 30 Mar 2017 13:42:09 +0200,
Ville Syrjälä wrote:
>
> On Wed, Mar 29, 2017 at 09:16:36PM +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-03-29 at 11:50 +0300, Ville Syrjälä wrote:
> > > On Tue, Mar 07, 2017 at 04:12:52PM -0800, Dhinakaran Pandiyan wrote:
> > > > According to BSpec, "The
On ke, 2017-03-29 at 23:04 +0100, Chris Wilson wrote:
> We pretty print the name of an engine in several places, mostly for
> debug, but also in the GPU hang report. Using "ring" in the name is
> archaic (we call those engines now to differentiate them from the
> multiple rings of commands we execu
On ke, 2017-03-29 at 19:28 +0100, Chris Wilson wrote:
> Create a substruct to hold all the global context state under
> drm_i915_private.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
On Thu, Mar 30, 2017 at 02:17:15PM +0200, Takashi Iwai wrote:
> On Thu, 30 Mar 2017 13:42:09 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Mar 29, 2017 at 09:16:36PM +, Pandiyan, Dhinakaran wrote:
> > > On Wed, 2017-03-29 at 11:50 +0300, Ville Syrjälä wrote:
> > > > On Tue, Mar 07, 2017 at 04:
== Series Details ==
Series: drm/i915: Enhanced disable access to stolen memory as a guest (rev3)
URL : https://patchwork.freedesktop.org/series/21818/
State : success
== Summary ==
Series 21818v3 drm/i915: Enhanced disable access to stolen memory as a guest
https://patchwork.freedesktop.org/a
Signed-off-by: Jani Nikula
---
bash_completion | 8
1 file changed, 8 insertions(+)
diff --git a/bash_completion b/bash_completion
index 7dfc4b86cb13..25c8c61f2eac 100644
--- a/bash_completion
+++ b/bash_completion
@@ -9,6 +9,11 @@ dim ()
fi
}
+_dim_git_branches()
+{
+
On ke, 2017-03-29 at 19:28 +0100, Chris Wilson wrote:
> If we move the actual cleanup of the context to a worker, we can allow
> the final free to be called from any context and avoid undue latency in
> the caller.
>
> Signed-off-by: Chris Wilson
> +static void free_contexts(struct work_struc
== Series Details ==
Series: drm/i915: Use a dummy timeline name for a signaled fence
URL : https://patchwork.freedesktop.org/series/22193/
State : success
== Summary ==
Series 22193v1 drm/i915: Use a dummy timeline name for a signaled fence
https://patchwork.freedesktop.org/api/1.0/series/221
On Thu, Mar 30, 2017 at 01:10:15PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Use a dummy timeline name for a signaled fence
> URL : https://patchwork.freedesktop.org/series/22193/
> State : success
>
> == Summary ==
>
> Series 22193v1 drm/i915: Use a dummy timeline n
On Thu, Mar 30, 2017 at 06:05:16PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's GVT-g update for 4.12. Major things are vGPU scheduler
> QoS support from Gao Ping, initial KBL support on E3 server from
> Han Xu.
>
> Note that QoS series depends on "drm/i915/gvt: adjust mem size for low
> resolu
On Thu, Mar 30, 2017 at 2:03 PM, Ville Syrjälä
wrote:
> On Wed, Mar 22, 2017 at 09:56:12PM +0100, 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 a
On 29/03/2017 23:04, Chris Wilson wrote:
We pretty print the name of an engine in several places, mostly for
debug, but also in the GPU hang report. Using "ring" in the name is
archaic (we call those engines now to differentiate them from the
multiple rings of commands we execute on each engine)
On Thu, Mar 30, 2017 at 09:37:15AM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Lukas Wunner wrote:
> > Just a bunch of trivial typos that caught my eye while perusing the
> > documentation.
> >
> > Signed-off-by: Lukas Wunner
>
> Reviewed-by: Jani Nikula
>
> Thanks, please push yourself!
I'm getting real lazy, let's start scripting this. Very rough draft,
but adds a Link: (patchwork tracks pull requests too, maybe we'll
start CI-ing them too), and sob line. In the future we might add more
checks here ...
Signed-off-by: Daniel Vetter
---
dim | 34 +
== Series Details ==
Series: drm/i915/uc: Misc cleanups
URL : https://patchwork.freedesktop.org/series/22194/
State : success
== Summary ==
Series 22194v1 drm/i915/uc: Misc cleanups
https://patchwork.freedesktop.org/api/1.0/series/22194/revisions/1/mbox/
Test gem_exec_flush:
Subgroup
On ke, 2017-03-29 at 19:28 +0100, Chris Wilson wrote:
> Whilst the contents of the context is still protected by the big
> struct_mutex, this is not much of an improvement. It is just one tiny
> step towards reducing our BKL.
>
> Signed-off-by: Chris Wilson
> + /* We opt for unserialised r
With the explicit retry loop static analyzers get confused by the
control flow and believe that e could be accessed after kfree. That's
not possible, but it's non-obvious, so let's clear it to NULL.
We already cleared e = NULL at the top of the function, so this is all
in line.
Cc: Julia Lawall
On Thu, Mar 30, 2017 at 04:32:37PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-03-29 at 19:28 +0100, Chris Wilson wrote:
> > Whilst the contents of the context is still protected by the big
> > struct_mutex, this is not much of an improvement. It is just one tiny
> > step towards reducing our BKL.
On Thu, Mar 30, 2017 at 03:27:57PM +0200, Daniel Vetter wrote:
> On Thu, Mar 30, 2017 at 2:03 PM, Ville Syrjälä
> wrote:
> > On Wed, Mar 22, 2017 at 09:56:12PM +0100, Daniel Vetter wrote:
> >> If we restrict this helper to only kms drivers (which is the case) we
> >> can look up the correct mode e
From: Tvrtko Ursulin
Tool which emits batch buffers to engines with configurable
sequences, durations, contexts, dependencies and userspace waits.
Unfinished but shows promise so sending out for early feedback.
First run the tool with no arguments to get the calibration number
which needs to be
We pretty print the name of an engine in several places, mostly for
debug, but also in the GPU hang report. Using "ring" in the name is
archaic (we call those engines now to differentiate them from the
multiple rings of commands we execute on each engine), quite verbose and
often tautological. We r
On ke, 2017-03-29 at 00:01 +, Vivi, Rodrigo wrote:
> On Tue, 2017-03-28 at 22:11 +, Srivatsa, Anusha wrote:
> > > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > @@ -61,6 +61,9 @@
> > > > #define KBL_FW_MAJOR 9
> > > > #define KBL_FW_MINOR 14
> > > >
> > > > +#define GLK_FW_MAJOR
On ke, 2017-03-29 at 10:54 +0300, Jani Nikula wrote:
> > On Wed, 29 Mar 2017, John Spotswood wrote:
> >
> > On Tue, 2017-03-21 at 17:29 -0700, Anusha Srivatsa wrote:
> > >
> > > +#define I915_GLK_HUC_UCODE HUC_FW_PATH(glk, GLK_HUC_FW_MAJOR, \
> > > + GLK_HUC_FW_MINOR, GLK_BLD_NUM)
> >
> > I thi
On Thu, Mar 30, 2017 at 02:45:53PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tool which emits batch buffers to engines with configurable
> sequences, durations, contexts, dependencies and userspace waits.
>
> Unfinished but shows promise so sending out for early feedback.
>
> Firs
ARM v6 (at least) only allows cmpxchg on 32bit variables which doesn't
always include the bool type.
drivers/built-in.o: In function `vblank_disable_and_save':
imx-ocotp.c:(.text+0xb45e8): undefined reference to `__bad_cmpxchg'
Makefile:986: recipe for target 'vmlinux' failed
Reported-by: kbuild
== Series Details ==
Series: drm: Clear e after kfree in drm_mode_page_flip_ioctl
URL : https://patchwork.freedesktop.org/series/22205/
State : success
== Summary ==
Series 22205v1 drm: Clear e after kfree in drm_mode_page_flip_ioctl
https://patchwork.freedesktop.org/api/1.0/series/22205/revis
On Thu, Mar 30, 2017 at 03:08:32PM +0100, Chris Wilson wrote:
> ARM v6 (at least) only allows cmpxchg on 32bit variables which doesn't
> always include the bool type.
>
> drivers/built-in.o: In function `vblank_disable_and_save':
> imx-ocotp.c:(.text+0xb45e8): undefined reference to `__bad_cmpxchg
== Series Details ==
Series: drm/i915: Drop verbose and archaic "ring" from our internal engine
names (rev2)
URL : https://patchwork.freedesktop.org/series/22128/
State : failure
== Summary ==
Series 22128v2 drm/i915: Drop verbose and archaic "ring" from our internal
engine names
https://pat
On Thu, Mar 30, 2017 at 02:25:35PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Drop verbose and archaic "ring" from our internal engine
> names (rev2)
> URL : https://patchwork.freedesktop.org/series/22128/
> State : failure
>
> == Summary ==
>
> Series 22128v2 drm/i9
Reviewed-by: Harry Wentland
On 2017-03-30 09:32 AM, Daniel Vetter wrote:
With the explicit retry loop static analyzers get confused by the
control flow and believe that e could be accessed after kfree. That's
not possible, but it's non-obvious, so let's clear it to NULL.
We already cleared e =
As we declare an engine as wedged, we mark all of its active requests as
in error. However, we don't want to mark successfully completed requests
as in error, which requires us to retire those requests first.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915
Having added the wait upon each engine to idle into the central
i915_gem_wait_for_idle(), we can remove the now redundant wait from
reset_all_global_seqno(). This has the advantage of removing the late
detection of an error (an engine still busy) which left the seqno reset
only partially complete (
If the driver is wedged, HW state may be very inconsistent and
report that it is still busy, even though we have stopped using it. This
can lead to a double *ERROR* rather than a graceful cleanup after
wedging.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i9
Make i915_gem_wait_for_idle() be a little heavier in order to try and
guarantee that the GPU is indeed idle (by checking each engine
individually is idle, i.e. all writes are complete and the rings
stopped) after waiting for in-flight requests to be completed.
v2: And return the final error.
v3: B
We can merge the pair of loops over the engines and their timelines into
a single loop, making it easier to read and more consistent with the
commentary.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
As we now distinguish everywhere that can call
i915_gem_retire_requests() following a successful wait_for_idle, we can
remove the duplication by moving that call into i915_gem_wait_for_idle()
itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
driv
One invariant on the order of requests on an engine is that they are
monotonically increasing. Assert that when we check retirement on the
ring that no request is more recent than the last submit request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 2 ++
1 file chan
On Thu, Mar 30, 2017 at 04:05:58PM +0100, Chris Wilson wrote:
> One invariant on the order of requests on an engine is that they are
> monotonically increasing. Assert that when we check retirement on the
> ring that no request is more recent than the last submit request.
>
> Signed-off-by: Chris
== Series Details ==
Series: series starting with [1/6] drm/i915: Do request retirement before
marking engines as wedged
URL : https://patchwork.freedesktop.org/series/22214/
State : failure
== Summary ==
Series 22214v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/ser
== Series Details ==
Series: drm/i915: Assert that the engine hasn't run backwards
URL : https://patchwork.freedesktop.org/series/22215/
State : success
== Summary ==
Series 22215v1 drm/i915: Assert that the engine hasn't run backwards
https://patchwork.freedesktop.org/api/1.0/series/22215/rev
On 25/03/17 07:23, Chris Wilson wrote:
It has been many years since the last confirmed sighting (and fix) of an
RC6 related bug (usually a system hang). Remove the parameter to stop
users from setting dangerous values.
This type of option can be useful for early debug and testing. Maybe it
c
On Thu, Mar 30, 2017 at 09:06:17AM -0700, Kelvin Gardiner wrote:
>
>
> On 25/03/17 07:23, Chris Wilson wrote:
> >It has been many years since the last confirmed sighting (and fix) of an
> >RC6 related bug (usually a system hang). Remove the parameter to stop
> >users from setting dangerous values
From: Tvrtko Ursulin
Since this can be triggered by simply attempting a huge object,
a WARN_ON is not appropriate.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu
On Thu, Mar 30, 2017 at 05:10:55PM +0100, Chris Wilson wrote:
> On Thu, Mar 30, 2017 at 09:06:17AM -0700, Kelvin Gardiner wrote:
> >
> >
> > On 25/03/17 07:23, Chris Wilson wrote:
> > >It has been many years since the last confirmed sighting (and fix) of an
> > >RC6 related bug (usually a system
On Thu, Mar 30, 2017 at 05:31:30PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Since this can be triggered by simply attempting a huge object,
> a WARN_ON is not appropriate.
>
> Signed-off-by: Tvrtko Ursulin
Hmm, true.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Ope
1 - 100 of 134 matches
Mail list logo
