On Mon, Jan 11, 2016 at 03:15:02PM +0200, Jani Nikula wrote:
> The changes since the sequence block v2 are:
>
> * The whole MIPI bios data block has a separate 32-bit size field since
> v3, stored after the version. This facilitates big sequences.
>
> * The size of the panel specific sequence b
On 01/11/2016 01:16 AM, Chris Wilson wrote:
> Ideally, we want to automagically have the GPU respond to the
> instantaneous load by reclocking itself. However, reclocking occurs
> relatively slowly, and to the client waiting for a result from the GPU,
> too late. To compensate and reduce the client
On Mon, Jan 11, 2016 at 03:31:27PM +0200, Jani Nikula wrote:
> On Mon, 11 Jan 2016, Jani Nikula wrote:
> > On Thu, 07 Jan 2016, Ville Syrjälä wrote:
> >> On Mon, Dec 21, 2015 at 03:11:02PM +0200, Jani Nikula wrote:
> >>> From: vkorjani
> >>>
> >>> New sequence element for i2c is been added in t
On 08/01/16 11:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 3 +--
drivers/gpu/drm/i915/intel_ringbuffer.
sanitize_watermarks() does not properly handle errors returned by
drm_atomic_helper_duplicate_state(). EDEADLK should trigger a modeset
backoff and retry; for other errors we need to drop locks before
returning.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Signed-off-by: Matt Roper
---
I think this
On Mon, Jan 11, 2016 at 03:45:08PM +, Dave Gordon wrote:
> >@@ -3647,7 +3643,10 @@ static inline bool __i915_request_irq_complete(struct
> >drm_i915_gem_request *req)
> > * but it is easier and safer to do it every time the waiter
> > * is woken.
> > */
> >-if (i915_gem_requ
Reviewed-by: Alex Dai
On 01/08/2016 07:03 AM, Peter Antoine wrote:
This commits adds the Broxton target to the GuC loader
Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
1 file changed, 7 inserti
Reviewed-by: Alex Dai
On 01/08/2016 07:03 AM, Peter Antoine wrote:
This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
spaces do not overlap.
Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_reg.h
Reviewed-by: Alex Dai
On 01/08/2016 07:03 AM, Peter Antoine wrote:
Per-context initialisation GPU instructions (which are injected directly
into the ringbuffer rather than being submitted as a batch) should not
be allowed to mix with user-generated batches in the same submission; it
will cause
== Summary ==
Built on e2edf9a8b66bd170acf15d13861bdf0c20a18f09 drm-intel-nightly:
2016y-01m-11d-14h-56m-49s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7)
pass -> DMESG-WARN (skl-i7k-2) UN
Chris Wilson writes:
> On Fri, Jan 08, 2016 at 03:51:19PM +0200, Mika Kuoppala wrote:
>> With commit 8ac3e1bb76cc ("drm/i915: Add non claimed mmio checking
>> for vlv/chv") we now have chv/vlv support in place for detecting
>> unclaimed access. Also the perf hit of extra mmio read
>> is now only
On Mon, Jan 11, 2016 at 05:36:46PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 11, 2016 at 03:16:16PM +, Tvrtko Ursulin wrote:
> > Don't know, I leave this one to whoever grabbed the lock around
> > intel_init_gt_powersave in the first place. Maybe there was a special
> > reason.. after git bla
On Mon, Jan 11, 2016 at 03:11:07PM +, Tvrtko Ursulin wrote:
>
> On 11/01/16 14:45, Chris Wilson wrote:
> >On Mon, Jan 11, 2016 at 02:21:33PM +, Tvrtko Ursulin wrote:
> >>
> >>On 22/12/15 17:40, Chris Wilson wrote:
> >>>On Tue, Dec 22, 2015 at 11:58:33AM +, Tvrtko Ursulin wrote:
> M
On 11/01/16 17:03, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 03:11:07PM +, Tvrtko Ursulin wrote:
>>
>> On 11/01/16 14:45, Chris Wilson wrote:
>>> On Mon, Jan 11, 2016 at 02:21:33PM +, Tvrtko Ursulin wrote:
On 22/12/15 17:40, Chris Wilson wrote:
> On Tue, Dec 22, 2015 at
Pushed the rest of the series *except* this patch. Thanks for the
review.
BR,
Jani.
On Mon, 11 Jan 2016, Jani Nikula wrote:
> I screwed up something, the authorship for this one should have remained
>
> From: vkorjani
>
> Can be fixed while applying, will not resend now.
>
> BR,
> Jani.
>
> O
On 11/01/16 09:17, Chris Wilson wrote:
In the next patch, request tracking is made more generic and for that we
need a new expanded struct and to separate out the logic changes from
the mechanical churn, we split out the structure renaming into this
patch.
v2: Writer's block. Add some spiel abo
Hello,
I am having problems connecting a external monitor to my laptop using a
intel HD 520 GPU and a Thunderbolt 3 adapter (Dell DA200).
My laptop is a Dell XPS 13 9350, running Slackware64-current with kernel
4.4.
Dmesg shows several errors related to the i915 kernel module.
What can I do?
On 11/01/16 16:16, Dave Gordon wrote:
On 08/01/16 11:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 3 +--
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, January 11, 2016 7:40 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC
>DP support on BXT
>
>On Tue, 2015
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, January 11, 2016 8:46 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Subject: Re: [PATCH 7/7] drm/i915/dp: Enable Upfront link training for typeC
>DP support on BXT
>
>On Fri, 2015-1
On Mon, 11 Jan 2016, Mário Antunes wrote:
> Hello,
>
> I am having problems connecting a external monitor to my laptop using a
> intel HD 520 GPU and a Thunderbolt 3 adapter (Dell DA200).
> My laptop is a Dell XPS 13 9350, running Slackware64-current with kernel
> 4.4.
> Dmesg shows several erro
On Mon, Dec 21, 2015 at 01:57:22PM +0200, Gabriel Feceoru wrote:
> On some HSW boards all pipeC tests fail with various dmesg errors.
> This seems to be caused by Pipe C beeing disabled in FUSE_STRAP and
> thus reading back the PIPECONF register is always zero.
>
> Fixed by adjusting pipe_count to
sanitize_watermarks() does not properly handle errors returned by
drm_atomic_helper_duplicate_state(). Make failures drop locks before
returning. We also change the lock of connection_mutex to a
drm_modeset_lock_all_ctx() to make sure any EDEADLK's are handled
earlier.
v2: Change call to lock co
On Tue, Jan 05, 2016 at 01:08:13PM +0200, Mika Kahola wrote:
> On Mon, 2016-01-04 at 18:53 +0200, Ville Syrjälä wrote:
> > On Mon, Jan 04, 2016 at 06:44:09PM +0200, Ville Syrjälä wrote:
> > > On Mon, Jan 04, 2016 at 01:21:24PM +0200, Mika Kahola wrote:
> > > > Don't use DP link training optimizatio
On Tue, Jan 05, 2016 at 03:50:02PM +0200, Mika Kahola wrote:
> Don't use DP link training optimization if channel EQ is not ok. It has
> been reported that in case of failure in channel EQ check the link training
> optimization can be enabled and therefore may not be able to reuse the
> previously
From: John Harrison
Split the execbuffer() function in half. The first half collects and
validates all the information required to process the batch buffer. It
also does all the object pinning, relocations, active list management,
etc - basically anything that must be done upfront before the IOCT
From: John Harrison
GPU page faults can now require scheduler operation in order to
complete. For example, in order to free up sufficient memory to handle
the fault the handler must wait for a batch buffer to complete that
has not even been sent to the hardware yet. Thus EAGAIN no longer
means a
From: John Harrison
When there are lots and lots and even more lots of contexts (e.g. when
running with execlists) it is useful to be able to immediately see
what the total context count is.
v4: Re-typed a variable (review feedback from Joonas)
For: VIZ-1587
Signed-off-by: John Harrison
Review
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM driver.
The general theory of operation is that when batch buffers are
submitted to the driver, the execbuffer() code assigns a unique seqno
value and then packages up all the information required to execute the
From: John Harrison
The scheduler needs to track interdependencies between batch buffers.
These are calculated by analysing the object lists of the buffers and
looking for commonality. The scheduler also needs to keep those
buffers locked long after the initial IOCTL call has returned to user
lan
From: John Harrison
The scheduler can cause batch buffers, and hence requests, to be
submitted to the ring out of order and asynchronously to their
submission to the driver. Thus at the point of waiting for the
completion of a given request, it is not even guaranteed that the
request has actually
From: John Harrison
If a high priority task was to continuously submit batch buffers to
the driver, it could starve out any lower priority task from getting
any GPU time at all. To prevent this, the priority of a queued batch
buffer is bumped each time it does not get submitted to the hardware.
From: John Harrison
The scheduler keeps its own lock on various DRM objects in order to
guarantee safe access long after the original execbuff IOCTL has
completed. This is especially important when pre-emption is enabled as
the batch buffer might need to be submitted to the hardware multiple
time
From: John Harrison
The seqno value cannot always be used when debugging issues via trace
points. This is because it can be reset back to start, especially
during TDR type tests. Also, when the scheduler arrives the seqno is
only valid while a given request is executing on the hardware. While
the
From: John Harrison
The scheduler has always tracked batch buffer dependencies based on
DRM object usage. This means that it will not submit a batch on one
ring that has outstanding dependencies still executing on other rings.
This is exactly the same synchronisation performed by
i915_gem_object_
From: John Harrison
Ring space is reserved when constructing a request to ensure that the
subsequent 'add_request()' call cannot fail due to waiting for space
on a busy or broken GPU. However, the scheduler jumps in to the middle
of the execbuffer process between request creation and request
subm
From: Dave Gordon
Keep a local copy of the request pointer in the _final() functions
rather than dereferencing the params block repeatedly.
v3: New patch in series.
For: VIZ-1587
Signed-off-by: Dave Gordon
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
with their submission to the hardware. This basically means splitting
the execbuffer() function in half. This change rearranges some code
ready for the split to occur.
For: VIZ-1587
Signed-off-by: John Harr
From: John Harrison
The seqno value is now only used for the final test for completion of
a request. It is no longer used to track the request through the
software stack. Thus it is no longer necessary to allocate the seqno
immediately with the request. Instead, it can be done lazily and left
unt
From: John Harrison
The GPU scheduler has added an execution priority level to the context
object. There is an IOCTL interface to allow user apps/libraries to
set this priority. This patch updates the context paramter IOCTL test
to include the new interface.
For: VIZ-1587
Signed-off-by: John Har
From: John Harrison
A major point of the GPU scheduler is that it re-orders batch buffers
after they have been submitted to the driver. This leads to requests
completing out of order. In turn, this means that the retire
processing can no longer assume that all completed entries are at the
front o
From: John Harrison
MMIO flips are the preferred mechanism now but more importantly, pipe
based flips cause issues for the scheduler. Specifically, submitting
work to the rings around the side of the scheduler could cause that
work to be lost if the scheduler generates a pre-emption event on that
From: John Harrison
Updated the execbuffer() code to pass the packaged up batch buffer
information to the scheduler rather than calling execbuffer_final()
directly. The scheduler queue() code is currently a stub which simply
chains on to _final() immediately.
For: VIZ-1587
Signed-off-by: John Ha
From: John Harrison
Added trace points to the scheduler to track all the various events,
node state transitions and other interesting things that occur.
v2: Updated for new request completion tracking implementation.
v3: Updated for changes to node kill code.
v4: Wrapped some long lines to kee
From: John Harrison
Now that all the scheduler patches have been applied, it is safe to enable.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/driver
From: John Harrison
One of the major purposes of the GPU scheduler is to avoid stalling
the CPU when the GPU is busy and unable to accept more work. This
change adds support to the ring submission code to allow a ring space
check to be performed before attempting to submit a batch buffer to
the h
From: John Harrison
A later patch in this series re-organises the batch buffer submission
code. Part of that is to reduce the scope of a pm_get/put pair.
Specifically, they previously wrapped the entire submission path from
the very start to the very end, now they only wrap the actual hardware
su
From: John Harrison
The TDR code needs to know what the scheduler is up to in order to
work out whether a ring is really hung or not.
v4: Removed some unnecessary braces to keep the style checker happy.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 30
From: John Harrison
To aid with debugging issues related to the scheduler, it can be
useful to ensure that all batch buffers are submitted immediately
rather than queued until later. This change adds an override flag via
the module parameter to force instant submission.
For: VIZ-1587
Signed-off-
From: John Harrison
The scheduler needs to do interrupt triggered work that is too complex
to do in the interrupt handler. Thus it requires a deferred work
handler to process such tasks asynchronously.
v2: Updated to reduce mutex lock usage. The lock is now only held for
the minimum time within
From: John Harrison
When requesting that all GPU work is completed, it is now necessary to
get the scheduler involved in order to flush out work that queued and
not yet submitted.
v2: Updated to add support for flushing the scheduler queue by time
stamp rather than just doing a blanket flush.
v
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
from their subsequent submission to the hardware. This means that an
application which is continuously submitting buffers as fast as it can
could potentialy flood the driver. To prevent this, the driver now
From: John Harrison
Added a facility for triggering the scheduler state dump via a debugfs
entry.
v2: New patch in series.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +
drivers/gpu/drm/i915/i915_scheduler.c | 9 ++
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
with submission of batch buffers to the hardware. Thus it is possible
for an application to close its DRM file handle while there is still
work outstanding. That means the scheduler needs to know about file
From: John Harrison
Initial creation of scheduler source files. Note that this patch
implements most of the scheduler functionality but does not hook it in
to the driver yet. It also leaves the scheduler code in 'pass through'
mode so that even when it is hooked in, it will not actually do very
m
From: John Harrison
When debugging batch buffer submission issues, it is useful to be able
to see what the current state of the scheduler is. This change adds
functions for decoding the internal scheduler state and reporting it.
v3: Updated a debug message with the new state_str() function.
v4:
From: John Harrison
The scheduler needs to know when requests have completed so that it
can keep its own internal state up to date and can submit new requests
to the hardware from its queue.
v2: Updated due to changes in request handling. The operation is now
reversed from before. Rather than th
From: Dave Gordon
Added an interface for user land applications/libraries/services to
set their GPU scheduler priority. This extends the existing context
parameter IOCTL interface to add a scheduler priority parameter. The
range is +/-1023 with +ve numbers meaning higher priority. Only
system pro
From: John Harrison
It is useful for know what the scheduler is doing for both debugging
and performance analysis purposes. This change adds a bunch of
counters and such that keep track of various scheduler operations
(batches submitted, completed, flush requests, etc.). The data can
then be read
From: John Harrison
Hardware sempahores require seqno values to be continuously
incrementing. However, the scheduler's reordering of batch buffers
means that the seqno values going through the hardware could be out of
order. Thus semaphores can not be used.
On the other hand, the scheduler super
From: John Harrison
When the seqno wraps around zero, the entire GPU is forced to be idle
for some reason (possibly only to work around issues with hardware
semaphores but no-one seems too sure!). This causes a problem if the
force idle occurs at an inopportune moment such as in the middle of
sub
From: John Harrison
If a given context submits too many hanging batch buffers then it will
be banned and no further batch buffers will be accepted for it.
However, it is possible that a large number of buffers may already
have been accepted and are sat in the scheduler waiting to be
executed. Thi
From: John Harrison
It is useful to be able to see what seqnos have actually popped out of
the hardware when viewing the scheduler status.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 ++
drivers/gpu/drm/i915/i915_scheduler.h | 1 +
2 files
From: John Harrison
It can be useful to be able to disable certain features (e.g. the
entire scheduler) via a module parameter for debugging purposes. A
parameter has the advantage of not being a compile time switch but
without implying that it can be changed dynamically at runtime.
For: VIZ-158
From: John Harrison
There are various parameters within the scheduler which can be tuned
to improve performance, reduce memory footprint, etc. This change adds
support for altering these via debugfs.
v2: Updated for priorities now being signed values.
For: VIZ-1587
Signed-off-by: John Harrison
From: Ville Syrjälä
Restore the lost phys status page cleanup.
Fixes the following splat with DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974
dma_debug_device_change+0x190/0x1f0()
pci :00:02.0: DMA-API: device driver has pending DMA allocations while
released from de
On 08/01/2016 21:59, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:22PM +, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic p
On 08/01/2016 22:05, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:24PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The fence object used inside the request structure requires a sequence
number. Although this is not used by the i915 driver itself, it could
potentially be us
On 08/01/2016 22:08, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:25PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The request structure is reference counted. When the count reached
zero, the request was immediately freed and all associated objects
were unrefereced/unalloc
Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
The main obstacle on these machines is that the panel mode in VBIOS
is bogus. Fortunately gmux can switch DDC independently from the
display, thereby allowing the inactive GPU to probe the panel's EDID.
In short, vga_switcheroo
On 08/01/2016 22:46, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:26PM +, john.c.harri...@intel.com wrote:
+void i915_gem_request_notify(struct intel_engine_cs *ring, bool fence_locked)
+{
+ struct drm_i915_gem_request *req, *req_next;
+ unsigned long flags;
u32 seqn
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS
if the vga_switcheroo h
gmux is a microcontroller built into dual GPU MacBook Pros.
On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux
to temporarily switch DDC so that we can probe the panel's EDID.
The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary
because if either of them is disabled
On 08/01/2016 22:47, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 06:47:21PM +, john.c.harri...@intel.com wrote:
[Patches against drm-intel-nightly tree fetched 17/11/2015]
Branch url?
Not sure what you mean. The branch is 'drm-intel-nightly' from the DRM
intel git repository (git://anong
On Mon, Dec 21, 2015 at 07:31:17AM -0800, Matt Roper wrote:
> In commit
>
> commit 024c9045221fe45482863c47c4b4c47d37f97cbf
> Author: Matt Roper
> Date: Thu Sep 24 15:53:11 2015 -0700
>
> drm/i915/skl: Eliminate usage of pipe_wm_parameters from
> SKL-style
On 11/01/16 08:38, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 11:29:44AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We are not allowed to call i915_gem_obj_ggtt_offset from irq
context without the big kernel lock held.
LRCA lifetime is well defined so cache it so it can be looked up
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 38 ++
drivers/gpu/drm/i915/intel_tv.c | 43 +--
3 files chan
Hi all, first real patches since the RFC at [1].
The VBT is a monster and it keeps growing. Originally we've extracted
bits and pieces out of there, and added them cleanly to our own
structures in dev_priv->vbt, with our own macros. Later on we've been
slipping and we have copied stuff from VBT ve
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 50
drivers/gpu/drm/i915/intel_lvds.c | 53 +--
3 files ch
Use the connector type instead of VBT directly to decide which backlight
mechanism to use on VLV/CHV. (Indirectly, this is the same thing, but
hides the VBT use.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 33 -
drivers/gpu/drm/i915/intel_dsi.c | 23 ++-
3 files changed, 47 insertio
Hide knowledge about VBT child devices in intel_bios.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 21 +
3 files changed, 35 insertions(
We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Signed-off-by: Jani Ni
On 11/01/16 09:16, Chris Wilson wrote:
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
Hi,
On Mon, Jan 11, 2016 at 09:54:36PM +0200, Jani Nikula wrote:
> Hi all, first real patches since the RFC at [1].
>
> The VBT is a monster and it keeps growing. Originally we've extracted
> bits and pieces out of there, and added them cleanly to our own
> structures in dev_priv->vbt, with our o
Hi,
On 5 January 2016 at 10:23, Daniel Vetter wrote:
> On Wed, Dec 23, 2015 at 09:47:00AM +, Daniel Stone wrote:
>> It's not even a legacy vs. atomic thing, this can happen in
>> pure-atomic as well. Same as the render-compression plane property
>> that I just replied to here as well.
>>
>> -
On Mon, Jan 11, 2016 at 05:15:54PM +, Tvrtko Ursulin wrote:
> > Is that not what was written? I take it my telepathy isn't working
> > again.
>
> Sorry not a new loop, new case in a old loop. This is the hunk I think
> is not helping readability:
>
> @@ -869,11 +967,29 @@ i915_gem_gtt_pwrite_
Hi all,
Mostly just small changes from review feedback (plus a few misplaced hunks,
silly me). Plus an attempt at better kerneldoc to explain how this works. Since
that caused questions both from Thomas and Laurent let me explain things also
here:
Currently anyone using drm_events (vblank code, a
Again since the core takes care of this we can remove them. While at
it also remove the postclose hook, it's empty.
v2: Laurent pointed me at even more code to delete.
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
d
Also fixes a bug in IPP with not correctly checking/allocating for
space in the event space. Not a too serious bug since it's not a
real ringbuffer, just a limit to avoid too much kernel allocations.
Cc: Rob Clark
Cc: Inki Dae
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Dan
Just prep work before I throw more drm_event refactorings on top.
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 48 +--
drivers/gpu/drm/drm_fops.c | 129 ++---
include/drm/
The core takes care of this now. And since kfree(NULL) is ok we can
simplify the function even further now.
Cc: Inki Dae
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
1 file changed, 14 deletions(
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
v2: Fixup misplaced hunk.
Cc: Laurent Pinchart
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher (v1)
Reviewed-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob
Now that the drm core unlinks/disarms events there's no need to do so
ourselves anymore. Nuke the code.
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 21
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/v
The compiler will do this, but the void hits when grepping all the
hooks for a subsystem wide audit are slightly annoying. So remove them
for next time around.
Cc: Russell King
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_drv.
The core takes care of that now.
v2: Fixup misplaced hunk.
Cc: Thierry Reding
Cc: Terje Bergström
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/dc.c | 17 -
drivers/gpu/drm/tegra/drm.c | 3 ---
drivers/gpu/drm/tegra
They only complete the page flip events to avoid oops when the drm
file closes. The core takes care of that now and we can remove this
code.
Cc: Rob Clark
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 7 ---
d
An attempt at not spreading out the file_priv->event_space stuff out
quite so far and wide. And I think fixes something in ipp_get_event()
that is broken (or if they are doing something more weird/subtle, then
breaks it in a fun way).
Based upon a patch from Rob Clark, rebased and polished.
v2:
The only thing this did was cancle pending flip events, and the core
takes care of that now.
Cc: Boris Brezillon
Acked-by: Daniel Stone
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 --
drivers/gpu/drm/atmel-hlcd
301 - 400 of 450 matches
Mail list logo
