Hey,
Op 20-09-16 om 20:45 schreef Mike Lothian:
> Hi
>
> I've bisected back to this commit in the drm-intel-nightly branch
>
> 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit
> commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460
> Author: Lyude
> Date: Wed Aug 17 15:55:57 2016 -040
On 09/19/2016 06:43 PM, Daniel Vetter wrote:
On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote:
On 8/31/2016 9:39 PM, Daniel Vetter wrote:
Big thing is untangling and carefully documenting the different uapi
types of planes. I also sprinkled a few more cross references around
to
On ti, 2016-09-20 at 09:29 +0100, Chris Wilson wrote:
> We currently capture the GPU state after we detect a hang. This is vital
> for us to both triage and debug hangs in the wild (post-mortem
> debugging). However, it comes at the cost of running some potentially
> dangerous code (since it has to
== Series Details ==
Series: series starting with [v7,1/6] drm/i915: Fallback to lower link rate and
lane count during link training (rev3)
URL : https://patchwork.freedesktop.org/series/12534/
State : success
== Summary ==
Series 12534v3 Series without cover letter
https://patchwork.freedesk
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes. To address these sce
From: "Pandiyan, Dhinakaran"
DP MST provides the capability to send multiple video and audio streams
through a single port. This requires the API's between i915 and audio
drivers to distinguish between multiple audio capable displays that can be
connected to a port. Currently only the port identi
Hi
I've bisected back to this commit in the drm-intel-nightly branch
05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit
commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460
Author: Lyude
Date: Wed Aug 17 15:55:57 2016 -0400
drm/i915/skl: Ensure pipes with changed wms get added to
Hi
I've bisected back to this commit in the drm-intel-nightly branch
05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit
commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460
Author: Lyude
Date: Wed Aug 17 15:55:57 2016 -0400
drm/i915/skl: Ensure pipes with changed wms get added to
Hi All,
Looking forward for more reviews comments and concerns if any, regarding this
patch.
Regards,
Anusha
>-Original Message-
>From: Jim Bride [mailto:jim.br...@linux.intel.com]
>Sent: Tuesday, September 6, 2016 11:57 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org
>S
== Series Details ==
Series: series starting with [v2,RESEND,1/2] drm/i915: Cleanup instdone
collection
URL : https://patchwork.freedesktop.org/series/12714/
State : warning
== Summary ==
Series 12714v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/12714/revisio
Hi Chris,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160920]
[cannot apply to v4.8-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --b
From: Ben Widawsky
Consolidate the instdone logic so we can get a bit fancier. This patch also
removes the duplicated print of INSTDONE[0].
v2: (Imre)
- Rebased on top of hangcheck INSTDONE changes.
- Move all INSTDONE registers into a single struct, store it within the
engine error struct dur
From: Ben Widawsky
v2: (Imre)
- Access only subslices that are known to exist.
- Reset explictly the MCR selector to slice/sub-slice ID 0 after the
readout.
- Use the subslice INSTDONE bits for the hangcheck/subunits-stuck
detection too.
- Take the uncore lock for the MCR-select/subslice-read
On pe, 2016-09-16 at 12:56 +0300, Jani Nikula wrote:
> On Tue, 06 Sep 2016, Mika Kuoppala
> wrote:
> > Imre Deak writes:
> >
> > > From: Ben Widawsky
> > >
> > > Consolidate the instdone logic so we can get a bit fancier. This
> > > patch also
> > > removes the duplicated print of INSTDONE[0].
Hi, I think there might be another clue on this one.
One of the comments is also mentioning an unfixed erratum of certain
Baytrail processors, named as "EOI Transaction May Not be Sent if
Software Enters Core C6 During an Interrupt Service Routine". This
erratum can be found on several differe
Imre Deak writes:
> From: Ben Widawsky
>
> v2: (Imre)
> - Access only subslices that are known to exist.
> - Reset explictly the MCR selector to slice/sub-slice ID 0 after the
> readout.
> - Use the subslice INSTDONE bits for the hangcheck/subunits-stuck
> detection too.
> - Take the uncore
Op 20-09-16 om 14:51 schreef Chris Wilson:
> On Tue, Sep 20, 2016 at 02:58:19PM +0300, Imre Deak wrote:
>> While user space has control over the scheduling priority of its page
>> flipping thread, the corresponding work the driver schedules for MMIO
>> flips always runs from the generic system work
On Tue, Sep 20, 2016 at 02:58:19PM +0300, Imre Deak wrote:
> While user space has control over the scheduling priority of its page
> flipping thread, the corresponding work the driver schedules for MMIO
> flips always runs from the generic system workqueue which has some
> scheduling overhead due i
On to, 2016-09-15 at 07:20 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Unlock PPS registers after GPU reset
> URL : https://patchwork.freedesktop.org/series/12446/
> State : success
Thanks for the report and review, I pushed it to -dinq.
>
> == Summary ==
>
> Series
== Series Details ==
Series: drm/i915: Queue page flip work with high priority (rev3)
URL : https://patchwork.freedesktop.org/series/12336/
State : warning
== Summary ==
Series 12336v3 drm/i915: Queue page flip work with high priority
https://patchwork.freedesktop.org/api/1.0/series/12336/revi
Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch make use of plane_wm variable directly instead of passing
> skl_plane_wm struct. this way reduces number of argument requirement
> in watermark calculation functions.
>
> It also gives more freedom of
While user space has control over the scheduling priority of its page
flipping thread, the corresponding work the driver schedules for MMIO
flips always runs from the generic system workqueue which has some
scheduling overhead due it being CPU bound. This would hinder an
application that wants more
ase=auto for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Allow-disabling-error-capture/20160920-164839
base:
drivers/gpu/drm/i915/i915_gem_request.c:256:42-43: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Chris Wilson
Signed-off-by: Fengguang Wu
---
i915_gem_request.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers
ase=auto for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Allow-disabling-error-capture/20160920-164839
base:
On Tue, Sep 20, 2016 at 09:46:58AM +0100, Lionel Landwerlin wrote:
> Some of the Intel platforms have odd numbers of LUT entries and we
> need to tests a couple of values around the expected result. Bring
> back the CRC equal function we need that doesn't trigger an assert
> right away, while we st
On Tue, 20 Sep 2016, Chris Wilson wrote:
> On Tue, Sep 20, 2016 at 11:57:06AM +0300, Jani Nikula wrote:
>> On Mon, 19 Sep 2016, Joonas Lahtinen wrote:
>> > On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
>> >> Fix sparse warnings:
>> >>
>> >> drivers/gpu/drm/i915/i915_drv.c:1179:5: warning:
Op 20-09-16 om 02:21 schreef Rodrigo Vivi:
> From: Mika Kuoppala
>
> Commit to a mode before querying it.
>
> Tested-by: Rodrigo Vivi
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97172
> Cc: Maarten Lankhorst
> Signed-off-by: Mika Kuoppala
> Signed-off-by: Rodrigo Vivi
> ---
> t
On Tue, Sep 20, 2016 at 11:57:06AM +0300, Jani Nikula wrote:
> On Mon, 19 Sep 2016, Joonas Lahtinen wrote:
> > On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> >> Fix sparse warnings:
> >>
> >> drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol
> >> 'i915_driver_load' was not declared.
== Series Details ==
Series: series starting with [01/38] drm/i915: Allow disabling error capture
URL : https://patchwork.freedesktop.org/series/12703/
State : failure
== Summary ==
Series 12703v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/12703/revisions/1/mb
On Tue, 20 Sep 2016, Ville Syrjälä wrote:
> On Mon, Sep 19, 2016 at 01:35:24PM +0300, Jani Nikula wrote:
>> CI got confused by all the patches flowing in the earlier thread, so
>> resend. No changes.
>
> Series lgtm.
>
> Reviewed-by: Ville Syrjälä
Thanks for the review, pushed to drm-intel-next-
On Mon, 19 Sep 2016, Joonas Lahtinen wrote:
> On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
>> Fix sparse warnings:
>>
>> drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol
>> 'i915_driver_load' was not declared. Should it be static?
>>
>> drivers/gpu/drm/i915/i915_drv.c:1267:6: warn
Some of the Intel platforms have odd numbers of LUT entries and we
need to tests a couple of values around the expected result. Bring
back the CRC equal function we need that doesn't trigger an assert
right away, while we still assert if we can't find a correct result in
the outter loop.
v2: updat
On Fri, 16 Sep 2016, Manasi Navare wrote:
> This patch series includes some of the remaining patches to enable
> upfront link training on DDI platforms for DP SST and MST.
> They are based on some of the patches submitted earlier by
> Ander and Durgadoss.
When you post new versions of an entire s
On Mon, Sep 19, 2016 at 01:35:24PM +0300, Jani Nikula wrote:
> CI got confused by all the patches flowing in the earlier thread, so
> resend. No changes.
Series lgtm.
Reviewed-by: Ville Syrjälä
>
> BR,
> Jani.
>
> Jani Nikula (1):
> drm/i915/backlight: setup and cache pwm alternate incremen
On Tue, Sep 20, 2016 at 11:20:38AM +0300, Marius Vlad wrote:
> Likely candidate for this behaviour is the igt_fixture block. Seen in the CI
> by
> running tests/kms_psr_sink_crc which is causing segfaults in the fixture
> block.
>
> While at it fix some minor printing bugs.
>
> Signed-off-by: M
In future patches, we will no longer be able to wait on a static global
seqno and instead have to break our wait up into phases. First we wait
for the global seqno assignment (upon submission to hardware), and once
submitted we wait for the hardware to complete.
Signed-off-by: Chris Wilson
Review
In the next patch, we will use deferred request emission. That requires
reserving sufficient space in the ringbuffer to emit the request, which
first requires us to know how large the request is.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_request.
With the infrastructure converted over to tracking multiple timelines in
the GEM API whilst preserving the efficiency of using a single execution
timeline internally, we can now assign a separate timeline to every
context with full-ppgtt.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915
The golden render state is constant, but we recreate the batch setting
it up for every new context. If we keep that batch in a volatile cache
we can safely reuse it whenever we need to initialise a new context. We
mark the pages as purgeable and use the shrinker to recover pages from
the batch when
Before suspend, we wait for the switch to the kernel context. In order
for all the other context images to be complete upon suspend, that
switch must be the last operation by the GPU (i.e. this idling request
must not overtake any pending requests). To make this request execute last,
we make it dep
A restriction on our global seqno is that they cannot wrap, and that we
cannot use the value 0. This allows us to detect when a request has not
yet been submitted, its global seqno is still 0, and ensures that
hardware semaphores are monotonic as required by older hardware. To
meet these restrictio
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is th
As we can locklessly (well struct_mutex-lessly) acquire the backing
storage, do so in set-domain-ioctl to reduce the contention on the
struct_mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 83 ++---
1 file changed, 53 insertions(+), 3
This will be used for communicating issues with this context to
userspace, so we want to identify the parent process and the individual
context. Note that the name isn't quite unique, it makes the presumption
of there only being a single device fd per process.
Signed-off-by: Chris Wilson
Reviewed
Move the actual emission of the request (the closing breadcrumb) from
i915_add_request() to the submit callback. (It can be moved later when
required.) This allows us to defer the allocation of the global_seqno
from request construction to actual submission, allowing us to emit the
requests out of
We want to hide the latency of releasing objects and their backing
storage from the submission, so we move the actual free to a worker.
This allows us to switch to struct_mutex freeing of the object in the
next patch.
Furthermore, if we know that the object we are dereferencing remains valid
for t
Though we will have multiple timelines, we still have a single timeline
of execution. This we can use to provide an execution and retirement order
of requests. This keeps tracking execution of requests simple, and vital
for preserving a single waiter (i.e. so that we can order the waiters so
that o
We only need struct_mutex within pwrite for a brief window where we need
to serialise with rendering and control our cache domains. Elsewhere we
can rely on the backing storage being pinned, and forgive userspace any
races against us.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem
A while ago we switched from a contiguous array of pages into an sglist,
for that was both more convenient for mapping to hardware and avoided
the requirement for a vmalloc array of pages on every object. However,
certain GEM API calls (like pwrite, pread as well as performing
relocations) do desir
Use the per-object mm.lock to allocate the backing storage (and hold a
reference to it across the dmabuf access) without resorting to
struct_mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 51 ++
1 file changed, 21 insertions(+), 30
Currently we try to reduce the number of synchronisations (now the
number of requests we need to wait upon) by noting that if we have
earlier waited upon a request, all subsequent requests in the timeline
will be after the wait. This only applies to requests in this timeline,
as other timelines wil
We only need struct_mutex within pread for a brief window where we need
to serialise with rendering and control our cache domains. Elsewhere we
can rely on the backing storage being pinned, and forgive userspace any
races against us.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.
Our timelines are more than just a seqno. They also provide an ordered
list of requests to be executed. Due to the restriction of handling
individual address spaces, we are limited to a timeline per address
space but we use a fence context per engine within.
Our first step to introducing independe
After combining the dma-buf reservation object and the GEM reservation
object, we lost the ability to do a nonblocking wait on the i915 request
(as we blocked upon the reservation object during prepare_fb). We can
instead convert the reservation object into a fence upon which we can
asynchronously
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
Since we only use the more generic unlocked variant, just rename it as
the normal i915_gem_active_wait(). The temporary cost is that we need to
always acquire the reference in a RCU safe manner, but the benefit is
that we will combine the common paths.
Signed-off-by: Chris Wilson
Reviewed-by: Joo
Add lockdep_assert_held(struct_mutex) to the API preamble of the
internal GEM interfaces.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 20
drivers/gpu/drm/i915/i915_gem_evict.c| 5 -
drivers/gpu/drm/i915/i915_gem_gtt.c
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/i915_gem.c | 21 ++---
drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +-
drivers/gpu/drm/i915/i915_gem_userptr.c |
drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more benefici
Break the allocation of the backing storage away from struct_mutex into
a per-object lock. This allows parallel page allocation, provided we can
do so outside of struct_mutex (i.e. set-domain-ioctl, pwrite, GTT
fault), i.e. before execbuf! The increased cost of the atomic counters
are hidden behind
Quite a few of our objects used for internal hardware programming do not
benefit from being swappable or from being zero initialised. As such
they do not benefit from using a shmemfs backing storage and since they
are internal and never directly exposed to the user, we do not need to
worry about pr
The plan is to make obtaining the backing storage for the object avoid
struct_mutex (i.e. use its own locking). The first step is to update the
API so that normal users only call pin/unpin whilst working on the
backing storage.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser
The plan is to move obj->pages out from under the struct_mutex into its
own per-object lock. We need to prune any assumption of the struct_mutex
from the get_pages/put_pages backends, and to make it easier we pass
around the sg_table to operate on rather than indirectly via the obj.
Signed-off-by:
We will need to wait on DMA completion (as signaled via struct fence)
before executing our i915_gem_request. Therefore we want to expose a
method for adding the await on the fence itself to the request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 40
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under
Since the GTT provides universal access to any GPU page, we can use it
to reduce our plethora of read methods to just one. It also has the
important characteristic of being exactly what the GPU sees - if there
are incoherency problems, seeing the batch as executed (rather than as
trapped inside the
Our low-level wait routine has evolved from our generic wait interface
that handled unlocked, RPS boosting, waits with time tracking. If we
push our GEM fence tracking to use reservation_objects (required for
handling multiple timelines), we lose the ability to pass the required
information down to
In forthcoming patches, we want to be able to dynamically allocate the
wait_queue_t used whilst awaiting. This is more convenient if we extend
the i915_sw_fence_await_sw_fence() to perform the allocation for us if
we pass in a gfp mask as an alternative than a preallocated struct.
Signed-off-by: C
We only need the active reference to keep the object alive after the
handle has been deleted (so as to prevent a synchronous gem_close). Why
then pay the price of a kref on every execbuf when we can insert that
final active ref just in time for the handle deletion?
Signed-off-by: Chris Wilson
---
A minor hitch in handling the unification of vma + obj retirements is
that we trigger a recursive use-after-free if we try to purge an object
with an active reference. One way to side-step that issue was to pull in
the deferred free work, which pulled in dependencies on the separate
mm.lock and a f
We currently capture the GPU state after we detect a hang. This is vital
for us to both triage and debug hangs in the wild (post-mortem
debugging). However, it comes at the cost of running some potentially
dangerous code (since it has to make very few assumption about the state
of the driver) that
Leave all the pretty printing to userspace and simplify the error
capture to only have a single common object printer. It makes the kernel
code more compact, and the refactoring allows us to apply more complex
transformations like compressing the output.
Signed-off-by: Chris Wilson
Reviewed-by: J
Our error states are quickly growing, pinning kernel memory with them.
The majority of the space is taken up by the error objects. These
compress well using zlib and without decode are mostly meaningless, so
encoding them does not hinder quickly parsing the error state for
familiarity.
v2: Make th
On Tue, Aug 30, 2016 at 10:30:54AM +0530, Nabendu Maiti wrote:
> Following patch series add pipe scaler functionality in atomic path.The pipe
> scaler can be changed dynamically without modeset.Apart from default panel
> fitter supported scaling modes -CENTER/ASPECT/FULLSCREEN custom scaling mode
>
In the fixture block for the test we receive a segfault with the
following trace:
0 setup_output (data=) at kms_psr_sink_crc.c:115
1 display_init (data=0x7ffd46833cf0) at kms_psr_sink_crc.c:126
2 main (argc=1, argv=) at kms_psr_sink_crc.c:528
And in setup_output(), output.config is:
$2 = {crt
Likely candidate for this behaviour is the igt_fixture block. Seen in the CI by
running tests/kms_psr_sink_crc which is causing segfaults in the fixture block.
While at it fix some minor printing bugs.
Signed-off-by: Marius Vlad
CC: Chris Wilson
---
lib/igt_core.c | 9 +
1 file changed
On Mon, 19 Sep 2016, James Bottomley
wrote:
> On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote:
>> On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote:
>> > Hi! James & Paulo: What's the current status of this?
>>
>> No, the only interaction has been the suggestion below for a rev
On Mon, 19 Sep 2016, Maarten Maathuis wrote:
> Any advice on how to proceed?
Please file a bug at [1].
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
___
80 matches
Mail list logo
