== Series Details ==
Series: Handle link training failure during modeset for DDI
URL : https://patchwork.freedesktop.org/series/14556/
State : failure
== Summary ==
Series 14556v1 Handle link training failure during modeset for DDI
https://patchwork.freedesktop.org/api/1.0/series/14556/revisio
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes
A new default connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training failed). If the link status property
is not good, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.
v2:
Squash the patch that returns the link rate index (Jani Nik
This defines a helper function to set the property value.
This will be used to set the link status to Bad in case
of link training failures.
v2:
* Simplify the return value (Jani Nikula)
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
S
Link training failure is handled by lowering the link rate/lane count
as per the Dp Spec 1.2 and sending a hotplug uevent to userspace to notify
that it needs to redo a modeset. This is notified by setting connector link
status property which should be tracked by userspace to take the action.
This
== Series Details ==
Series: HuC Loading Patches
URL : https://patchwork.freedesktop.org/series/14555/
State : success
== Summary ==
Series 14555v1 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/14555/revisions/1/mbox/
Test drv_module_reload_basic:
dmesg-
These patches add HuC loading support. The userspace
patches that check for a fully loaded HuC firmware and use
it can be found at:
https://lists.freedesktop.org/archives/libva/2016-September/004554.html
https://lists.freedesktop.org/archives/libva/2016-September/004555.html
v2: rebased.
v3: reba
From: Peter Antoine
This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased.
changed file name to match the install package format.
v7: rebased.
v8: rebased.
Signed-off-by: Anusha Srivatsa
Signed-off-by: Peter Antoine
Reviewed-by: David Gordo
From: Peter Antoine
Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw'
From: Peter Antoine
Add debugfs entry for HuC loading status check.
v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave
From: Peter Antoine
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
v2: rebased on-top of drm-intel-nigh
From: Peter Antoine
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5:
From: Peter Antoine
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before t
From: Peter Antoine
This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after i
On Fri, Oct 28, 2016 at 11:38:14PM +0200, Paul Bolle wrote:
> On Sat, 2016-10-29 at 00:30 +0300, Ville Syrjälä wrote:
> > I think it was probably due to
> >
> > commit 44d1240d006c9cd0249263b5449c8e4752500f6a
> > Author: Marek Szyprowski
> > Date: Mon Jun 13 11:11:26 2016 +0200
> >
> > drm
On Sat, 2016-10-29 at 00:30 +0300, Ville Syrjälä wrote:
> I think it was probably due to
>
> commit 44d1240d006c9cd0249263b5449c8e4752500f6a
> Author: Marek Szyprowski
> Date: Mon Jun 13 11:11:26 2016 +0200
>
> drm: add generic zpos property
>
> If you want want to grade my answer all you
On Fri, Oct 28, 2016 at 11:05:48PM +0200, Paul Bolle wrote:
> On Fri, 2016-10-28 at 19:59 +0300, ville.syrj...@linux.intel.com wrote:
> > Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's
> > were active.")
>
> Obviously, I'm pretty happy with this patch. One question thoug
On Fri, 2016-10-28 at 19:59 +0300, ville.syrj...@linux.intel.com wrote:
> Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were
> active.")
Obviously, I'm pretty happy with this patch. One question though: this
fixes a commit that shipped in v4.6. Do you have any idea why
On Fri, Oct 28, 2016 at 01:46:51PM +0300, Petri Latvala wrote:
> On Thu, Oct 13, 2016 at 03:00:43PM +0100, Chris Wilson wrote:
> > Add the two basic gem_wait tests to the fast list, together they take a
> > total of 1s (when correctly functioning).
> >
> > Signed-off-by: Chris Wilson
> > ---
> >
On Fri, Oct 28, 2016 at 04:17:46PM -0200, Paulo Zanoni wrote:
> Em Qua, 2016-10-26 às 15:51 -0700, Matt Roper escreveu:
> > This was the only use of (misleadingly-named) intel_num_planes()
> > function, so we can remove it as well.
>
> This one has a trivial conflict with Maarten's series. Same co
On 28/10/16 15:27, Chris Wilson wrote:
We are not allowed to touch the GTT entries underneath an atomic section,
as they take a rpm wakelock (which is illegal from atomic context) and
in the near future acquiring the DMA address for a page within an object
may sleep for an allocation. This make
Em Qua, 2016-10-26 às 15:51 -0700, Matt Roper escreveu:
> This was the only use of (misleadingly-named) intel_num_planes()
> function, so we can remove it as well.
This one has a trivial conflict with Maarten's series. Same comment as
p1 regarding merging.
Reviewed-by: Paulo Zanoni
>
> Signed-
Em Qua, 2016-10-26 às 15:51 -0700, Matt Roper escreveu:
> This macro's name is a bit misleading; it doesn't actually iterate
> over
> all planes since it omits the cursor plane. Its only uses are in
> gen9
> code which is using it to iterate over the universal planes (which we
> treat as primary+s
== Series Details ==
Series: drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
URL : https://patchwork.freedesktop.org/series/14540/
State : success
== Summary ==
Series 14540v1 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing
things
https://patchwork.freedesktop.o
From: Ville Syrjälä
When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from
On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote:
> On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote:
> > On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> > > On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > > > Hi,
> > > >
> > > > After hibernat
On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote:
> On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote:
> > On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> > > On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > > > Hi,
> > > >
> > > > After hibernat
On Fri, Oct 28, 2016 at 06:47:26PM +0300, Abdiel Janulgue wrote:
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Abdiel Janulgue
> ---
> tests/kms_flip.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> index 9829b35..13
On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote:
> On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> > On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > > Hi,
> > >
> > > After hibernation I get the following error when I tried to connect to
> > > monit
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Abdiel Janulgue
---
tests/gem_wait.c | 125 ---
1 file changed, 7 insertions(+), 118 deletions(-)
diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index b4127de..630058c 100644
--- a/tests/gem
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Abdiel Janulgue
---
tests/kms_flip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 9829b35..13cb262 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -866,10 +866,10 @@ st
Generalized from auto-tuned GPU dummy workload in gem_wait and kms_flip
v2 : Add recursive batch feature from Chris
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Abdiel Janulgue
---
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_dummyload.c | 613
A lot of igt testcases need some GPU workload to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overtly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that should consu
On Fri, 2016-10-28 at 13:49 +0100, Chris Wilson wrote:
> Some subsystem polices have a strict requirement that every patch must
> have at least one reviewer before being approved for upstream. Since
> encouraging review is good policy (great review is even better policy!)
> enforce checking for a R
== Series Details ==
Series: drm/i915: Remove insert-page shortcut from execbuf relocate_iomap()
URL : https://patchwork.freedesktop.org/series/14532/
State : success
== Summary ==
Series 14532v1 drm/i915: Remove insert-page shortcut from execbuf
relocate_iomap()
https://patchwork.freedesktop
> +/* Note we copy the properties from userspace outside of the i915 perf
> + * mutex to avoid an awkward lockdep with mmap_sem.
> + *
> + * Note this function only validates properties in isolation it doesn't
> + * validate that the combination of properties makes sense or that all
> + * propertie
We are not allowed to touch the GTT entries underneath an atomic section,
as they take a rpm wakelock (which is illegal from atomic context) and
in the near future acquiring the DMA address for a page within an object
may sleep for an allocation. This makes the current shortcircuit in
relocation_io
== Series Details ==
Series: series starting with [CI,01/35] drm/i915: Support asynchronous waits on
struct fence from i915_gem_request
URL : https://patchwork.freedesktop.org/series/14531/
State : warning
== Summary ==
Series 14531v1 Series without cover letter
https://patchwork.freedesktop.
On Fri, Oct 28, 2016 at 04:33:10PM +0300, Jani Nikula wrote:
> On Fri, 28 Oct 2016, Chris Wilson wrote:
> > Some subsystem polices have a strict requirement that every patch must
> > have at least one reviewer before being approved for upstream. Since
> > encouraging review is good policy (great r
On Wed, Oct 26, 2016 at 03:36:32PM -0400, Lyude wrote:
> Now that these have finally made it into 4.9, it's time to finally backport
> these fixes. Skylake has been a mess in multi-monitor setups for a while now
> because up until recently we've been updating the watermarks on Skylake just
> like w
== Series Details ==
Series: scripts/checkpatch: Check for Reviewed-by under --strict
URL : https://patchwork.freedesktop.org/series/14529/
State : warning
== Summary ==
Series 14529v1 scripts/checkpatch: Check for Reviewed-by under --strict
https://patchwork.freedesktop.org/api/1.0/series/145
On Fri, 28 Oct 2016, Chris Wilson wrote:
> Some subsystem polices have a strict requirement that every patch must
> have at least one reviewer before being approved for upstream. Since
> encouraging review is good policy (great review is even better policy!)
> enforce checking for a Reviewed-by wh
== Series Details ==
Series: drm/i915: Convert breadcrumbs spinlock to be irqsafe (rev4)
URL : https://patchwork.freedesktop.org/series/14488/
State : failure
== Summary ==
Series 14488v4 drm/i915: Convert breadcrumbs spinlock to be irqsafe
https://patchwork.freedesktop.org/api/1.0/series/1448
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.
v2: Add a comment to indicate the xfer between timelines up
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
Having moved the locked phase of freeing an object to a separate worker,
we can now declare to the core that we only need the unlocked variant of
driver->gem_free_object, and can use the simple unreference internally.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/
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
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
Now that the emission of the request tail and its submission to hardware
are two separate steps, engine->emit_request() is confusing.
engine->emit_request() is called to emit the breadcrumb commands for the
request into the ring, name it such (engine->emit_breadcrumb).
Signed-off-by: Chris Wilson
Move the actual emission of the breadcrumb for closing the request 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 o
In the next patch, we will use deferred breadcrumb emission. That requires
reserving sufficient space in the ringbuffer to emit the breadcrumb, which
first requires us to know how large the breadcrumb is.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem
Defer the assignment of the global seqno on a request to its submission.
In the next patch, we will only allocate the global seqno at that time,
here we are just enabling the wait-for-submission before wait-for-seqno
paths.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gp
The breadcrumbs are about to be used from within IRQ context sections
(e.g. nouveau signals a fence from an interrupt handler causing us to
submit a new request) and/or from bottom-half tasklets (i.e.
intel_lrc_irq_handler), therefore we need to employ the irqsafe spinlock
variants.
For example, d
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
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
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
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
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
Reviewed-by: Joonas Lahtinen
---
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
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 69 +++---
1 file
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
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 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
Reviewed-by: Joonas Lahtinen
---
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
Reviewed-by: Tvrtko Ursulin
Reviewed-by:
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
Add lockdep_assert_held(struct_mutex) to the API preamble of the
internal GEM interfaces.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 21 +
drivers/gpu/drm/i
We can use the radixtree index of the obj->pages to find the start
position of the desired partial range.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 40 -
1 file changed, 26 insertions(+), 14 deletions(-)
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
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
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 99 +
1 fil
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
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
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
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
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
The throttle-ioctl never touches the struct_mutex. It does, however, as
part of its ABI report whether the hardware is terminally wedged. For
that purposes, it only has to report the current state and not incur the
cost of checking/waiting every invocation, as we do not have to wait for
a reset bef
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.
v2: Add a comment detailing a failure to handle a signal-on-any
fence-array.
v3: Pretend that m
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
Rev
Some subsystem polices have a strict requirement that every patch must
have at least one reviewer before being approved for upstream. Since
encouraging review is good policy (great review is even better policy!)
enforce checking for a Reviewed-by when checkpath is run with --strict
(or with --revie
On 10/28/16 1:48 AM, Jani Nikula wrote:
On Fri, 28 Oct 2016, Fabian Pie wrote:
Hi,
I'm testing Baytrail device with mipi/dsi display and hdmi output. When I
boot without the hdmi connected the mipi/dsi works OK and after connecting
the hdmi both mipi/dsi and hdmi display graphics OK.
If I boot
Attaching old discussion thread for easy reference.
On Tue, Jan 05, 2016 at 05:18:40PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 05, 2016 at 03:50:38PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 04, 2016 at 07:06:15PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 04, 2016 at 11:16:39AM +0100,
== Series Details ==
Series: drm/i915: Convert breadcrumbs spinlock to be irqsafe (rev3)
URL : https://patchwork.freedesktop.org/series/14488/
State : failure
== Summary ==
Series 14488v3 drm/i915: Convert breadcrumbs spinlock to be irqsafe
https://patchwork.freedesktop.org/api/1.0/series/1448
On Fri, 28 Oct 2016, Jani Nikula wrote:
> On Thu, 27 Oct 2016, Manasi Navare wrote:
>> This work struct will be used to schedule a uevent on a separate
>> thread. This will be scheduled after a link train failure during modeset
>> to indicate a modeset retry request. It will get executed after th
On Thu, 27 Oct 2016, Manasi Navare wrote:
> This is required to return the index of link rate into
> common_rates array. This gets used to retry the link
> training at lower link rate.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
Please squash thi
The breadcrumbs are about to be used from within IRQ context sections
(e.g. nouveau signals a fence from an interrupt handler causing us to
submit a new request) and/or from bottom-half tasklets (i.e.
intel_lrc_irq_handler), therefore we need to employ the irqsafe spinlock
variants.
For example, d
On Thu, 27 Oct 2016, Manasi Navare wrote:
> From: "Navare, Manasi D"
>
> These static helper functions are required to be used during
> fallback link rate implemnetation so they need to be placed at the top
> of the file.
>
> v3:
> * Add cleanup to other patch (Mika Kahola)
> v2:
> * Dont move ar
Attaching old discussion thread for easy reference.
On Tue, Jan 05, 2016 at 05:18:40PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 05, 2016 at 03:50:38PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 04, 2016 at 07:06:15PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 04, 2016 at 11:16:39AM +0100,
On Thu, 27 Oct 2016, Manasi Navare wrote:
> This defines a helper function to set the property value.
> This will be used to set the link status to Bad in case
> of link training failures.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Ch
On Thu, 27 Oct 2016, Manasi Navare wrote:
> This work struct will be used to schedule a uevent on a separate
> thread. This will be scheduled after a link train failure during modeset
> to indicate a modeset retry request. It will get executed after the
> current modeset is complete and all locks
== Series Details ==
Series: drm/i915/gen9+: Whitelist TIMESTAMP register from BLT ring (rev2)
URL : https://patchwork.freedesktop.org/series/14482/
State : warning
== Summary ==
Series 14482v2 drm/i915/gen9+: Whitelist TIMESTAMP register from BLT ring
https://patchwork.freedesktop.org/api/1.0
On 28/10/16 12:30, Chris Wilson wrote:
On Fri, Oct 28, 2016 at 12:26:09PM +0100, Chris Wilson wrote:
On Fri, Oct 28, 2016 at 11:49:34AM +0100, Tvrtko Ursulin wrote:
On 28/10/16 11:42, Chris Wilson wrote:
On Fri, Oct 28, 2016 at 11:27:43AM +0100, Tvrtko Ursulin wrote:
On 28/10/16 11:10,
On to, 2016-10-27 at 17:10 +0100, Chris Wilson wrote:
> @@ -473,14 +477,14 @@ static int intel_breadcrumbs_signaler(void *arg)
> * we just completed - so double check we are still
> * the oldest before picking the next one.
>
On Fri, Oct 28, 2016 at 12:30:55PM +0100, Chris Wilson wrote:
> On Fri, Oct 28, 2016 at 12:26:09PM +0100, Chris Wilson wrote:
> > On Fri, Oct 28, 2016 at 11:49:34AM +0100, Tvrtko Ursulin wrote:
> > >
> > >
> > > On 28/10/16 11:42, Chris Wilson wrote:
> > > >On Fri, Oct 28, 2016 at 11:27:43AM +010
On Fri, Oct 28, 2016 at 12:26:24PM +0100, Chris Wilson wrote:
> After hotplug notification, userspace has to reprobe all connectors to
> detect any changes. This can be expensive (some outputs may require time
> consuming load detection, some outputs may simply be slow to respond)
> and not all out
The breadcrumbs are about to be used from within IRQ context sections,
and/or from bottom-half tasklets (i.e. intel_lrc_irq_handle), therefore
we need to employ the irqsafe spinlock variants.
[ 66.388639] =
[ 66.388650] [ INFO: inconsistent lock state ]
[ 66.3
On Fri, Oct 28, 2016 at 12:26:09PM +0100, Chris Wilson wrote:
> On Fri, Oct 28, 2016 at 11:49:34AM +0100, Tvrtko Ursulin wrote:
> >
> >
> > On 28/10/16 11:42, Chris Wilson wrote:
> > >On Fri, Oct 28, 2016 at 11:27:43AM +0100, Tvrtko Ursulin wrote:
> > >>
> > >>
> > >>On 28/10/16 11:10, Chris Wils
After hotplug notification, userspace has to reprobe all connectors to
detect any changes. This can be expensive (some outputs may require time
consuming load detection, some outputs may simply be slow to respond)
and not all outputs need to be checked everytime. The kernel is usually
in a very goo
On Fri, Oct 28, 2016 at 11:49:34AM +0100, Tvrtko Ursulin wrote:
>
>
> On 28/10/16 11:42, Chris Wilson wrote:
> >On Fri, Oct 28, 2016 at 11:27:43AM +0100, Tvrtko Ursulin wrote:
> >>
> >>
> >>On 28/10/16 11:10, Chris Wilson wrote:
> >>>On Fri, Oct 28, 2016 at 10:42:22AM +0100, Tvrtko Ursulin wrote:
On Thu, Oct 27, 2016 at 04:22:31PM +0100, Chris Wilson wrote:
> On Thu, Oct 27, 2016 at 03:05:16PM +0100, Chris Wilson wrote:
> > Use a priority stored in the context as the initial value when
> > submitting a request. This allows us to change the default priority on a
> > per-context basis, allowi
1 - 100 of 124 matches
Mail list logo
