Some stress tests create both the signal helper and a lot of competing
processes. In these tests, the parent is just waiting upon the children,
and the intention is not to keep waking up the waiting parent, but to
keep interrupting the children (as we hope to trigger races in our
kernel code). kill
gem_concurrent_blit tries to ensure that it doesn't try and run a test
that would grind the system to a halt, i.e. unexpectedly cause swap
thrashing. It currently calls intel_require_memory(), but outside of
the subtest (as the tests use fork, it cannot do requirement testing
within the test childr
Hi,
On 07/01/16 21:34, Belgaumkar, Vinay wrote:
On Wed, Jan 06, 2016 at 03:00:39PM +, Michel Thierry wrote:
i915 validates that requested offset is in canonical form, so tests need
to convert the offsets as required.
Also add test to verify non-canonical 48-bit address will be rejected.
hello,
I have updated a Toshiba R600 from Centos 7.1 to 7.2 and now the display is
blurred (background, letters, ... but not menus) and time to time disk
manager (nemo) don't start.
if I reboot on the previous kernel (of 7.1 version) , all is ok
Any hint ?
The Centos Forum cannot help me.
With
On ma, 2015-11-23 at 11:38 +, john.c.harri...@intel.com wrote:
> 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.
>
> Change-Id: If9726d4d
On Fri, 08 Jan 2016, Frederic Corne wrote:
> hello,
>
> I have updated a Toshiba R600 from Centos 7.1 to 7.2 and now the display is
> blurred (background, letters, ... but not menus) and time to time disk
> manager (nemo) don't start.
>
> if I reboot on the previous kernel (of 7.1 version) , all i
Hide away the platform differences in intel_dsi_get_pckl() within
intel_dsi_pll.c. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 9 ++---
drivers/gpu/drm/i915/intel_dsi.h | 3 +--
drivers/gpu/drm/i915/intel_dsi_pll.c | 12 ++--
3 f
The dsi_rr_formula() function has been unused for almost two years,
since
commit 44d4c6eebb2ef04f698c292bb6eda5f2e80c663b
Author: Shobhit Kumar
Date: Tue Dec 10 12:14:56 2013 +0530
drm/i915: Compute dsi_clk from pixel clock
citing the reason as pixel clock based calculation being recommen
On Fri, Jan 08, 2016 at 12:45:39PM +0200, Jani Nikula wrote:
> Hide away the platform differences in intel_dsi_get_pckl() within
> intel_dsi_pll.c. No functional changes.
>
> Signed-off-by: Jani Nikula
For the series
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 9
From: Tvrtko Ursulin
Random cleanups from yesterday mutated into a bit of locking verification and
fixing as suggested by Daniel Vetter.
Replacig list_for_each_entry with a dedicated i915_gem_obj_for_each_vma which
asserts the struct_mutex uncovered a few holes, not all of which (atomic display
From: Tvrtko Ursulin
Same effect for slightly less source code and resulting binary.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/in
From: Tvrtko Ursulin
Looks like the sleeping loop in __i915_wait_request can be
simplified by using io_schedule_timeout instead of setting
up and destroying a timer.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 28
1 file ch
From: Tvrtko Ursulin
There is no need to check on what Gen we are running on every
interrupt and every command submission. We can instead set up
some of that when engines are initialized, store it in the
engine structure and use it directly at runtime.
Signed-off-by: Tvrtko Ursulin
---
drivers
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
cheaply from the interrupt context and at command submission
time.
v2: Added irq context reasoning to the
From: Tvrtko Ursulin
LRCA can change only when it goes from unpinned to pinned so it
makes sense to check its alignment at that point rather than at
every batch buffer submission.
Furthermore, if we check it at pin time we can actually
gracefuly fail the engine initialization rather than just
sp
From: Tvrtko Ursulin
Purpose is to catch places which iterate the object VMA list
without holding the big lock.
Implemented by open coding list_for_each_entry to make the
macro compatible with existing call sites.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_
From: Tvrtko Ursulin
Purpose is to catch places which iterate the object VMA list
without holding the big lock.
Implemented by open coding list_for_each_entry_safe to make
the macro compatible with existing call sites.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/
From: Tvrtko Ursulin
Purpose is catching illegal callers.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81a
From: Tvrtko Ursulin
Engine initialization would have failed if those two weren't
pinned and calling i915_gem_obj_is_pinned is illegal from irq
context without the big lock held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 2 --
1 file changed, 2 deletions(-)
diff --g
From: Tvrtko Ursulin
No need to call ktime_get_raw_ns twice per unlimited wait and can
also elimate a local variable.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
to the object backing store in the context in order to avoid
walking over the object SG page list from the interrupt context
without the big lock held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i91
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.c | 3 +++
drivers/gpu/drm/i915/intel_ringbuf
On Fri, 08 Jan 2016, Ville Syrjälä wrote:
> On Fri, Jan 08, 2016 at 12:45:39PM +0200, Jani Nikula wrote:
>> Hide away the platform differences in intel_dsi_get_pckl() within
>> intel_dsi_pll.c. No functional changes.
>>
>> Signed-off-by: Jani Nikula
>
> For the series
> Reviewed-by: Ville Syrjäl
On Fri, Jan 08, 2016 at 11:29:51AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Purpose is catching illegal callers.
I know you didn't try benchmarking this.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing
On Fri, Jan 08, 2016 at 11:29:50AM +, 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.
No. Move to tracking VMA.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Jan 08, 2016 at 11:29:39AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Random cleanups from yesterday mutated into a bit of locking verification and
> fixing as suggested by Daniel Vetter.
Rather than duplicating my work, please do help fix the bugs that are
impeding moving f
On Fri, Jan 08, 2016 at 11:29:47AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> VMA creation and GEM list management need the big lock.
No, this operation doesn't require locking.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
On Tue, Jan 05, 2016 at 05:01:15PM +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 Fri, Jan 08, 2016 at 11:29:46AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Purpose is to catch places which iterate the object VMA list
> without holding the big lock.
>
> Implemented by open coding list_for_each_entry to make the
> macro compatible with existing call sites.
>
>
On Fri, Jan 08, 2016 at 11:40:56AM +, Chris Wilson wrote:
> On Fri, Jan 08, 2016 at 11:29:47AM +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > VMA creation and GEM list management need the big lock.
>
> No, this operation doesn't require locking.
My bad, there's a vm->list tra
On Tue, Jan 05, 2016 at 05:08:17PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>
On 08/01/16 11:40, Chris Wilson wrote:
On Fri, Jan 08, 2016 at 11:29:47AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
No, this operation doesn't require locking.
You can argue about positioning and such, but it is adding it to
On Fri, Jan 08, 2016 at 11:47:03AM +, Tvrtko Ursulin wrote:
>
> On 08/01/16 11:40, Chris Wilson wrote:
> >On Fri, Jan 08, 2016 at 11:29:47AM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>VMA creation and GEM list management need the big lock.
> >
> >No, this operation doesn't
,
>
> [auto build test WARNING on drm-intel/for-linux-next]
> [also build test WARNING on next-20160108]
> [cannot apply to v4.4-rc8]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.c
Hi,
Comments below.
On ma, 2015-11-23 at 11:38 +, john.c.harri...@intel.com wrote:
> From: Dave Gordon
>
> Added various definitions that will be useful for the scheduler in
> general and
> pre-emptive context switching in particular.
>
> Change-Id: Ica805b94160426def51f5d520f5ce51c60864a9
On ma, 2015-11-23 at 11:38 +, john.c.harri...@intel.com wrote:
> 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 f
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
v2:
Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
Not to mention drm_gem_object_unreference was there in existing
code with no mutex held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i91
On Thu, Jan 07, 2016 at 06:27:24PM -0800, Kumar, Abhay wrote:
>
>
> On 1/7/2016 10:15 AM, Ville Syrjälä wrote:
> > On Mon, Dec 21, 2015 at 05:18:52PM -0800, abhay.ku...@intel.com wrote:
> >> From: Abhay Kumar
> >>
> >> Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
> >>
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
v2:
Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
Not to mention drm_gem_object_unreference was there in existing
code with no mutex held.
v3:
Some callers of i915_gem_object_create_stolen_for_
On 08/01/16 11:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Purpose is to catch places which iterate the object VMA list
without holding the big lock.
Implemented by open coding list_for_each_entry to make the
macro compatible with existing call sites.
Signed-off-by: Tvrtko Ursulin
Cc: Da
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 suffered if mmio_debug is set.
This allows us to stuff the macro for unclaimed reg
detection inside
If we go into suspend with unclaimed access detected,
it would be nice to catch that access on a next suspend path.
So instead of just notifying about it, arm the unclaimed
mmio checks on suspend side.
We want to keep the asymmetry on resume, as if it was
on resume path, it was not driver that is
On Fri, Jan 08, 2016 at 03:51:20PM +0200, Mika Kuoppala wrote:
> If we go into suspend with unclaimed access detected,
> it would be nice to catch that access on a next suspend path.
> So instead of just notifying about it, arm the unclaimed
> mmio checks on suspend side.
>
> We want to keep the a
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 suffered if mmio_debug is set
Chris Wilson writes:
> On Tue, Dec 01, 2015 at 05:56:12PM +0200, Mika Kuoppala wrote:
>> If head seems stuck and engine in question is rcs,
>> inspect subunit state transitions from undone to done,
>> before deciding that this really is a hang instead of limited
>> progress. Only account the tran
Ville Syrjälä writes:
> On Tue, Dec 15, 2015 at 07:45:42PM +0200, Mika Kuoppala wrote:
>> Imre mentioned that chv might also have capability to
>> track unclaimed mmio accesses. Ville added that
>> both chv and vlv has this capability and he had already
>> made this way back [1]. Mimic what Ville
This set of patches will enable the GuC loading for BXT.
There is also a fix that is required for GuC submission with the BXT GuC
to make it reliable.
Peter Antoine (3):
drm/i915: Adding Broxton GuC Loader Support
drm/i915: resize the GuC WOPCM for rc6
drm/i915: Wait after context init with
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 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/g
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 | 3 ++-
drivers/gpu/drm/i915/intel_guc_loader.c | 5 +
2 files chan
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 confusion for the GuC (which might merge a subsequent
preemptive reques
On Fri, Jan 08, 2016 at 04:54:19PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Tue, Dec 01, 2015 at 05:56:12PM +0200, Mika Kuoppala wrote:
> >> If head seems stuck and engine in question is rcs,
> >> inspect subunit state transitions from undone to done,
> >> before deciding that
Chris Wilson writes:
> On Tue, Dec 15, 2015 at 04:25:06PM +0200, Mika Kuoppala wrote:
>> Access the unclaimed reg detection register through
>> one helper which also does cleanup. Note that we now access
>> the register only if the platform has the actual non claimed
>> access bit. This prevents
On Fri, Jan 08, 2016 at 03:03:54PM +, 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
Jani Nikula writes:
> On Thu, 19 Nov 2015, Daniel Vetter wrote:
>> On Thu, Nov 19, 2015 at 11:41:07AM +0200, Mika Kuoppala wrote:
>>> Daniel Vetter writes:
>>>
>>> > On Mon, Nov 02, 2015 at 11:25:08AM +0200, Mika Kuoppala wrote:
>>> >> Gen9 has had demonstrated cases where forcing a not ready
On Fri, Jan 08, 2016 at 06:31:44PM +0200, Mika Kuoppala wrote:
> I think we should forget this and only resurrect it
> if we ever again see failed resets.
Bingo! I have been able to wedge the machine (bdw and bsw) recently so badly
that
the resets failed with the "reset request timeout".
-Chris
Store the edram capabilities instead of only the size of
edram. This is preparatory patch to allow edram size calculation
based on edram capability bits for gen9+.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 7 +--
driv
With gen9+ the edram capabilities are defined so
that we can calculate the edram (ellc) size accordingly.
Note that there are undefined combinations for some subset of
edram capability bits. Return the closest size for undefined indexes.
Even if we get it wrong with beginning of future gen enablin
On Sun, Jan 03, 2016 at 08:04:27AM -0800, Marc MERLIN wrote:
> My hunch at this point is that google-chrome-beta is taxing the GPU and
> causing the driver to misbehave. I'm now back to
> 2:2.99.917+git20151217-1~exp1 and 4.3.3 and will run google-chrome-beta
> --disable-gpu, but this kills other s
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 problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there should not
be a need for a 'signaled' function to be called everytime the status
is queried. Instead, 'something' should be done to enable a signal
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 used by non-i915 code if the fence is passed outside of
the driver. This is the intention as it allows external kernel dr
From: John Harrison
Added the '_complete' trace event which occurs when a fence/request is
signaled as complete. Also moved the notify event from the IRQ handler
code to inside the notify function itself.
v3: Added the current ring seqno to the notify trace point.
v5: Line wrapping to keep the
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 problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
The change to the implementation of i915_gem_request_completed() means
that the lazy coherency flag is no longer used. This can now be
removed to simplify the interface.
For: VIZ-5190
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
requirement of not enabling interrupts until requested. However, when
interrupts are enabled the IRQ handle can be called multiple times
withou
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/unallocated. This meant that the driver mutex lock
must be held at the point where the count reaches zero. This was fine
while
From: Ville Syrjälä
Looks like I fumbled things when I made kms_chv_cursor_fail iterate
over all pipes. It fails to check that the pipe actually exists, and
so fails on < 3 pipe platforms. Add the necessary checks to skip
on non-existing pipes.
Signed-off-by: Ville Syrjälä
---
tests/kms_chv_cu
When userspace closes a handle, we remove it from the file->object_idr
and then tell the driver to drop its references to that file/handle.
However, as the file/handle is already available again for reuse, it may
be reallocated back to userspace and active on a new object before the
driver has had
Hi all,
This patch series is inspired by a WIP patch from Rob Clark to consolidate the
drm_event handling a bit. I've went a bit further and also moved the pending
event handling and unlinking into the core, which allows us to nuke a bunch of
code from drivers who all copypasted this themselves. P
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.
Cc:
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
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --g
Cc: Rob Clark
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/vmwgfx/vmwgfx_fence.c
index 8e689b439890..eda93bf52a
There's really no reason to not do so, instead of replicating this
for every use-case and every driver. Now we can't just nuke the events,
since that would still mean that all drm_event users would need to know
when that has happened, since calling e.g. drm_send_event isn't allowed
any more. Instea
I'm auditing them all, empty ones just confuse ...
Cc: Patrik Jakobsson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 92e7e5795398..4e1c68505
Use them in the core vblank code and exynos/vmwgfx drivers.
Note that the difference between wake_up_all and _interruptible in
vmwgfx doesn't matter since the only waiter is the core code in
drm_fops.c. And that is interruptible.
Cc: Thomas Hellstrom
Cc: Inki Dae
Signed-off-by: Daniel Vetter
-
Now that the drm core unlinks/disarms events there's no need to do so
ourselves anymore. Nuke the code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 21 -
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 f
The only thing this did was cancle pending flip events, and the core
takes care of that now.
Cc: Boris Brezillon
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 --
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 10 --
drivers/gpu/d
Doesn't do anything, but annoys when auditing them all.
Cc: Jianwei Wang
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
inde
Just prep work before I throw more drm_event refactorings on top.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 48 +--
drivers/gpu/drm/drm_fops.c | 129 ++---
include/drm/drmP.h | 17 +++---
3 files changed, 1
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 20
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 8
2 files changed, 2
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 20
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 --
drivers/gpu/drm/rcar-du/rcar_d
The core takes care of this now. And since kfree(NULL) is ok we can
simplify the function even further now.
Cc: Inki Dae
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 2 --
drivers/gpu/drm/tegra/drm.h | 1 -
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 20 ---
Again since the core takes care of this we can remove them. While at
it also remove the postclose hook, it's empty.
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 29 -
1 file changed, 29 deletions(-)
d
The core takes care of that now.
Cc: Thierry Reding
Cc: Terje Bergström
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/dc.c | 17 -
drivers/gpu/drm/tegra/drm.c | 3 ---
2 files changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/d
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter enter the commit message
for your changes. Lines starting
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20
drivers/gpu/drm/vc4/vc4_drv.c |
So this one is special, since it tries to prevent races when userspace
crashes simply by disabling the vblank machinery. Well except that imx
always has vblanks enabled, and the disable_vblank hook actually just
tries to cancel a pending pageflip. Without any locking whatsoever. Of
course this is w
Again since the drm core takes care of event unlinking/disarming this
is now just needless code.
Cc: Thomas Hellström
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 -
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 38 -
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
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 7 ---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 11 --
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
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_
On 01/08/2016 09:36 PM, Daniel Vetter wrote:
> Again since the drm core takes care of event unlinking/disarming this
> is now just needless code.
>
> Cc: Thomas Hellström
> Signed-off-by: Daniel Vetter
Hmm,
IIRC this is actually a list of events that core drm is not aware of
yet. They sit on thi
On Fri, Jan 8, 2016 at 3:36 PM, Daniel Vetter wrote:
> 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).
>
Unknown parameters, especially structure padding, are expected to invoke
rejection with -EINVAL.
Testcase: igt/gem_ctx_bad_destroy/invalid-pad
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89602
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_context.c |
On Fri, Jan 8, 2016 at 3:36 PM, Daniel Vetter wrote:
> Hi all,
>
> This patch series is inspired by a WIP patch from Rob Clark to consolidate the
> drm_event handling a bit. I've went a bit further and also moved the pending
> event handling and unlinking into the core, which allows us to nuke a b
On Mon, Jan 04, 2016 at 01:16:54PM -0800, Jesse Barnes wrote:
> On 01/04/2016 12:57 PM, Chris Wilson wrote:
> > On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote:
> >> So this one has my ack.
> >
> > This series makes a number of fundamental mistakes in seqno-interrupt
> > handling, so
On 01/08/2016 01:47 PM, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 01:16:54PM -0800, Jesse Barnes wrote:
>> On 01/04/2016 12:57 PM, Chris Wilson wrote:
>>> On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote:
So this one has my ack.
>>>
>>> This series makes a number of fundamental
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 problem that the drivers 'struct
>
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 used by non-i915 code if the fence i
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/unallocated. This meant that the driver m
1 - 100 of 108 matches
Mail list logo
