On Fri, Feb 10, 2017 at 07:59:13PM +, Chris Wilson wrote:
> The warnings from parsing the EDID are not driver errors, but the
> "normal but significant" conditions from the external device. As such,
> they do not need the ferocity of an *ERROR*, but can use the less harsh
> DRM_NOTE instead.
>
== Series Details ==
Series: series starting with [1/2] mm: Handle prefault for size >= 2GB
URL : https://patchwork.freedesktop.org/series/19533/
State : success
== Summary ==
Series 19533v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/19533/revisions/1/mbox/
f
From: "sagar.a.kam...@intel.com"
With prefaulting extended to support >=2GB, i915 can handle
relocation objects >=2GB. type conversion of length from int to
unsigned long in access_ok was making the validation bail out with
-EFAULT.
Testcase: igt/gem_exec_reloc/wc-31
Cc: Daniel Vetter
Cc: Chris
From: "sagar.a.kam...@intel.com"
i915 gem_exec_reloc subtests *-31 exercise relocation entries object
that is of size >=2GB. This patch will allow prefaulting >=2GB size.
Cc: Daniel Vetter
Cc: Chris Wilson
Signed-off-by: Sagar Arun Kamble
---
include/linux/pagemap.h | 6 --
1 file change
On Friday, January 27, 2017 9:42:00 AM PST Robert Bragg wrote:
> Folds in Matthew Auld's feedback; thanks.
>
> Robert Bragg (5):
> drm/i915/perf: fix gen7_append_oa_reports comment
> drm/i915/perf: avoid poll, read, EAGAIN busy loops
> drm/i915/perf: avoid read back of head register
> drm/
Link to FDO regression list:
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=DRM%2FIntel&f0=OP&f1=OP&f2=short_desc&f3=keywords&f4=CP&f5=CP&j1=OR&known_name=i915%20regressions&list_id=600614&o2=anywordssubstr&o3=anywordss
== Series Details ==
Series: series starting with [1/2] drm/i915: Pass timeout==0 on to
i915_gem_object_wait_fence()
URL : https://patchwork.freedesktop.org/series/19523/
State : success
== Summary ==
Series 19523v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/
If we wait up on the full (i.e. all shared fences, or upon an exclusive fence)
reservation object successfully, we know that all fences beneath it have
been signaled, so long as no new fences were added whilst we slept. If the
reservation_object remains the same, as detected by its seqcount, we can
The i915_gem_object_wait_fence() uses an incoming timeout=0 to query
whether the current fence is busy or idle, without waiting. This can be
used by the wait-ioctl to implement a busy query.
Fixes: e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with
callers")
Testcase: igt/gem_
== Series Details ==
Series: series starting with [1/5] drm/i915: Assert that the active request
hasn't been signaled
URL : https://patchwork.freedesktop.org/series/19518/
State : failure
== Summary ==
Series 19518v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
Following a hang and reset, we know that the engine is idle and all
context state has been saved or lost. Consequently, we know that the
engine is no longer referencing the last context and we can relinquish
our tracking.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
dri
As i915_gem_reset_finish() undoes the steps from
i915_gem_reset_prepare() to leave the system in a fully-working state,
e.g. to be able to free the breadcrumb signal threads, make sure that we
always call it even on the error path.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c
The signal threads may be running concurrently with the GPU reset. The
completion from the GPU run asynchronous with the reset and two threads
may see different snapshots of the state, and the signaler may mark a
request as complete as we try to reset it. We don't tolerate 2 different
views of the
Disabling the tasklet leaves it if scheduled on the ready to run list
until it is re-enabled. This will leave the ksoftird thread spinning
until satisfied. To prevent this situation on starting the GPU reset, we
want to kill the tasklet first and then disable. The same problem will
arise when a tas
As the request is not complete, it should not be signaled. Assert that
this is true before we process the request for a reset.
References: https://bugs.freedesktop.org/show_bug.cgi?id=99671
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
d
== Series Details ==
Series: softirq: Prevent looping on disabled tasklets (rev3)
URL : https://patchwork.freedesktop.org/series/19515/
State : success
== Summary ==
Series 19515v3 softirq: Prevent looping on disabled tasklets
https://patchwork.freedesktop.org/api/1.0/series/19515/revisions/3/
On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote:
> +void tasklet_enable(struct tasklet_struct *t)
> +{
> + if (!atomic_dec_and_test(&t->count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, &t->state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTI
Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq
== Series Details ==
Series: softirq: Prevent looping on disabled tasklets (rev2)
URL : https://patchwork.freedesktop.org/series/19515/
State : failure
== Summary ==
Series 19515v2 softirq: Prevent looping on disabled tasklets
https://patchwork.freedesktop.org/api/1.0/series/19515/revisions/2/
-disabled-tasklets/20170212-220435
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "raise_softirq"
-disabled-tasklets/20170212-220435
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "raise_softirq"
== Series Details ==
Series: softirq: Prevent looping on disabled tasklets
URL : https://patchwork.freedesktop.org/series/19515/
State : failure
== Summary ==
CHECK usr/include/linux/dvb/ (8 files)
CHECK usr/include/linux/android/ (1 files)
CHECK usr/include/linux/byteorder/ (2 fil
Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq
On Sun, Feb 12, 2017 at 02:00:19PM +, Chris Wilson wrote:
> Disabling a tasklet causes it not to run during tasklet_action, but is
> put back onto the runnable tasklet list, and a new softirq raised. As
> the softirq is raised from within __do_softirq() this causing
> __do_softirq() to loop con
== Series Details ==
Series: drm/i915: fix for WaDisableDopClockGating:bdw (rev2)
URL : https://patchwork.freedesktop.org/series/19332/
State : success
== Summary ==
Series 19332v2 drm/i915: fix for WaDisableDopClockGating:bdw
https://patchwork.freedesktop.org/api/1.0/series/19332/revisions/2/
On Sun, Feb 12, 2017 at 12:44:49AM +, Chris Wilson wrote:
> The signal threads may be running concurrently with the GPU reset. The
> completion from the GPU run asynchronous with the reset and two threads
> may see different snapshots of the state, and the signaler may mark a
> request as compl
Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq
This workaround for BDW was incomplete as it also requires EUTC clock
gating to be disabled via UCGCTL1.
v2: read modify write UCGTL1 in broadwell_init_clock_gating (Ville)
Signed-off-by: Robert Bragg
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8
drivers/gpu/drm/i
On Wed, Feb 8, 2017 at 6:33 PM, Ville Syrjälä
wrote:
> On Wed, Feb 08, 2017 at 06:10:31PM +, Robert Bragg wrote:
>> This workaround for BDW was incomplete as it also requires EUTC clock
>> gating to be disabled via UCGCTL1.
>
> IIRC that matches what I told Ben years ago when the w/a was first
On Sun, Feb 12, 2017 at 10:31:48AM +, Chris Wilson wrote:
> Disabling the tasklet leaves it if scheduled on the ready to run list
> until it is re-enabled. This will leave the ksoftird thread spinning
> until satisfied. To prevent this situation on starting the GPU reset, we
> want to kill the
Hi Maarten,
Do you plan to post a v4 ? I have two drivers that depends on this series for
fence support, and I'd like to get that merged in v4.12.
On Monday 16 Jan 2017 10:37:37 Maarten Lankhorst wrote:
> Fourth iteration. Instead of trying to convert all drivers straight away,
> implement all m
Hi Maarten,
Thank you for the patch.
On Monday 16 Jan 2017 10:37:38 Maarten Lankhorst wrote:
> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> replace the old for_each_xxx_in_state ones. This is useful for >1 flip
> depth and getting rid of all xxx->state dereferences.
>
>
Hi Daniel,
On Monday 23 Jan 2017 09:48:54 Daniel Vetter wrote:
> On Thu, Jan 19, 2017 at 12:56:29AM +0200, Laurent Pinchart wrote:
> > On Tuesday 17 Jan 2017 08:41:03 Maarten Lankhorst wrote:
> >> Op 17-01-17 om 00:11 schreef Laurent Pinchart:
> >>> On Monday 16 Jan 2017 10:37:38 Maarten Lankhorst
== Series Details ==
Series: drm/i915: Kill the tasklet then disable
URL : https://patchwork.freedesktop.org/series/19512/
State : success
== Summary ==
Series 19512v1 drm/i915: Kill the tasklet then disable
https://patchwork.freedesktop.org/api/1.0/series/19512/revisions/1/mbox/
fi-bdw-5557u
Disabling the tasklet leaves it if scheduled on the ready to run list
until it is re-enabled. This will leave the ksoftird thread spinning
until satisfied. To prevent this situation on starting the GPU reset, we
want to kill the tasklet first and then disable. The same problem will
arise when a tas
Howdy,
I have a thinkpad P70 (skylake)
After upgrading to the latest git driver in debian:
Unpacking xserver-xorg-video-intel (2:2.99.917+git20161206-1) over
(2:2.99.917+git20160218-1) ...
Unpacking xserver-common (2:1.19.1-4) over (2:1.18.1-1) ...
the intel driver doesn't work in Xorg anymore
36 matches
Mail list logo
