On Sun, 2016-12-18 at 13:36 -0800, Rodrigo Vivi wrote:
> Let's take usage of IS_LP to simplify the gem stolen
> initialization as suggest by Tvrtko.
>
> Also assume that all new LP platforms follows the chv+
> and others bdw+.
>
> Broxton and Geminilake were probably using the incorrect path
> so
Op 15-12-16 om 18:26 schreef Ville Syrjälä:
> On Thu, Dec 15, 2016 at 06:42:08PM +0200, Ville Syrjälä wrote:
>> On Thu, Dec 15, 2016 at 04:41:51PM +0100, Maarten Lankhorst wrote:
>>> Op 15-12-16 om 16:36 schreef Ville Syrjälä:
On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote:
On 12/16/2016 12:45 PM, Chris Wilson wrote:
On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:
From: Arun Siluvery
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU re
On 12/16, Fengguang Wu wrote:
>Hi Daniel,
>
>On Fri, Dec 16, 2016 at 08:29:43AM +0100, Daniel Vetter wrote:
>>Hi Kbuild folks
>>
>>So yeah this doesn't apply because it's just 1 patch resent out of a
>>big patch series, in-reply-to the patch it replaces. So applying this
>>alone and telling me (and
2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
>> Rendering operations to the dma-buf are tracked implicitly via the
>> reservation_object (dmabuf->resv). This is used to allow poll() to
>> wait upon outstanding rendering (or just quer
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=anywords
== Series Details ==
Series: series starting with [1/3] drm/i915: Expand is_lp backwards to gen8_lp
and gen7_lp.
URL : https://patchwork.freedesktop.org/series/16967/
State : success
== Summary ==
Series 16967v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/1696
gen8 is used for both Broadwell and Cherryview but this
function here is only Cherryview and all next atom LP platforms.
So let's rename it to avoid confusion as suggested by Ville.
Cc: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 4 ++--
1 file changed
Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp)
are both Atom platforms like Broxton/Apollolake and Geminilake.
So let's expand this is_lp back to these platforms and
create the IS_LP(dev_priv) so we can start simplifying a bit
our if/else for platform lists.
Signed-off-by: Rodrig
Let's take usage of IS_LP to simplify the gem stolen
initialization as suggest by Tvrtko.
Also assume that all new LP platforms follows the chv+
and others bdw+.
Broxton and Geminilake were probably using the incorrect path
so far.
Cc: Ander Conselvan de Oliveira
Cc: Imre Deak
Cc: Mika Kuoppal
== Series Details ==
Series: drm/i915: Repeat flush of idle work during suspend
URL : https://patchwork.freedesktop.org/series/16964/
State : success
== Summary ==
Series 16964v1 drm/i915: Repeat flush of idle work during suspend
https://patchwork.freedesktop.org/api/1.0/series/16964/revisions
The idle work handler is self-arming - if it detects that it needs to
run again it will queue itself from its work handler. Take greater care
when trying to drain the idle work, and double check that it is flushed.
The free worker has a similar issue where it is armed by an RCU task
which may be r
== Series Details ==
Series: series starting with [CI,1/7] drm/i915: Add a reminder that
i915_vma_move_to_active() requires struct_mutex
URL : https://patchwork.freedesktop.org/series/16963/
State : success
== Summary ==
Series 16963v1 Series without cover letter
https://patchwork.freedesktop
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc
A few users only take the struct_mutex in order to release a reference
to a context. We can expose a kref_put_mutex() wrapper in order to
simplify these users, and optimise taking of the mutex to the final
unref.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i
Just a simple move to avoid a forward declaration, though the diff likes
to present itself as a move of intel_logical_ring_alloc_request_extras()
in the opposite direction.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 132 +++
PIN_HIGH is an expensive operation (in comparison to allocating from the
hole stack) unsuitable for frequent use (such as switching between
contexts). However, the kernel context should be pinned just once for
the lifetime of the driver, and here it is appropriate to keep it out of
the mappable ran
A fairly trivial move of a matching pair of routines (for preparing a
request for construction) onto an engine vfunc. The ulterior motive is
to be able to create a mock request implementation.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_request.c |
As the shadow gvt is not user accessible and does not have an associated
vm, we can mark it as closed during its construction. This saves leaking
the internal knowledge of i915_gem_context into gvt/.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gvt/scheduler.
i915_vma_move_to_active() requires the struct_mutex for serialisation
with retirement, so mark it up with lockdep_assert_held().
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> > On Fri, 16 Dec 2016, Daniel Vetter wrote:
> > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> > >> The two remaining patches from [1], rebased.
> > >>
On Fri, Dec 16, 2016 at 10:03:32AM -0500, Sean Paul wrote:
> On Tue, Dec 13, 2016 at 6:08 PM, Daniel Vetter wrote:
> > - Modeset state needs mode_config->connection mutex, that covers
> > figuring out the encoder, and reading properties (since in the
> > atomic case those need to look at conne
On Sun, Dec 18, 2016 at 02:35:45PM +0100, Daniel Vetter wrote:
> If we're unlucky then the registration from a hotplugged connector
> might race with the final registration step on driver load. And since
> MST topology discover is asynchronous that's even somewhat likely.
>
> v2: Also update the k
If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.
v2: Also update the kerneldoc for @registered!
v3: Review from Chris:
- Improve kerneldoc for
24 matches
Mail list logo
