On 07/03/2017 20:58, Chris Wilson wrote:
If the worker fails, it no longer has pages to release and can be
immediately removed from the invalidate-tree.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 ++
1 file changed, 2
On 07/03/2017 20:58, Chris Wilson wrote:
To avoid waiting for work from other invalidate-range threads where
not required, only wait on the userptr cancel workqueue if we have added
some work to it.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915
On Tue, 07 Mar 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> printks are slow so we should not be doing them from the vblank evade
> critical section. These could explain why we sometimes seem to
> blow past our 100 usec deadline.
>
> The problem has been there ever since co
On 07/03/2017 20:58, Chris Wilson wrote:
If we allow the user to convert a GTT mmap address into a userptr, we
may end up in recursion hell, where currently we hit a mutex deadlock
but other possibilities include use-after-free during the
unbind/cancel_userptr.
[ 143.203989] gem_userptr_bli D
On Tue, 07 Mar 2017, Maxime Ripard wrote:
> I just rebased my tree on top of the latest drm-misc tag
> (drm-misc-next-2017-03-06). It should compile, and not have merge
> conflicts anymore.
Conflicts happen. Rebasing should not be the standard operating
procedure for fixing them.
BR,
Jani.
--
Hi ville:
thanks for acked-by and will fix that missing space :)
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, March 08, 2017 12:13 AM
To: Niu, Bing
Cc: intel-gfx@lists.freedesktop.org; Lv, Zhiyuan ; Wang,
Zhi A
Subject: Re: [Intel-gfx][
From: Bing Niu
under virtualization enviroment, it is possible guest update pipe
registers across vblank intervals due to overhead of mmio traps or vm
schedule out. However, it is safe since those pipe update happen in
virual registers and will not be committed to hardware. suppress that
atomic c
On Tue, Mar 7, 2017 at 7:59 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the sunxi tree got a conflict in:
>
> drivers/gpu/drm/sun4i/sun4i_drv.c
>
> between commit:
>
> 50480a78e282 ("drm: sun4i: use vblank hooks in struct drm_crtc_funcs")
>
> from the drm-misc tree an
== Series Details ==
Series: drm/i915: suppress atomic commit error message under gvt-g env (rev3)
URL : https://patchwork.freedesktop.org/series/20600/
State : failure
== Summary ==
Series 20600v3 drm/i915: suppress atomic commit error message under gvt-g env
https://patchwork.freedesktop.org
On Wed, 08 Mar 2017, "Srivatsa, Anusha" wrote:
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>>Arkadiusz Hiler
>>Sent: Tuesday, March 7, 2017 7:25 AM
>>To: intel-gfx@lists.freedesktop.org
>>Subject: [Intel-gfx] [PATCH 10/10] drm/i915/u
On Tue, Mar 07, 2017 at 08:58:49PM +, Chris Wilson wrote:
> If the worker fails, it no longer has pages to release and can be
> immediately removed from the invalidate-tree.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> Cc: Tvrtko Ursulin
Reviewed-by: Michał Winiarski
-Michał
On Tue, Mar 07, 2017 at 08:58:50PM +, Chris Wilson wrote:
> To avoid waiting for work from other invalidate-range threads where
> not required, only wait on the userptr cancel workqueue if we have added
> some work to it.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> Cc: Tvrtko Ur
Op 07-03-17 om 21:54 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> printks are slow so we should not be doing them from the vblank evade
> critical section. These could explain why we sometimes seem to
> blow past our 100 usec deadline.
>
> The problem has been there ever since
Op 01-03-17 om 10:52 schreef Daniel Vetter:
> The trouble here is that looking at all connector->state in the
> verifier isn't good, because that's run from the commit work, which
> doesn't hold the connection_mutex. Which means we're only allowed to
> look at states in our atomic update.
>
> The s
On Fri, 20 Jan 2017, Mika Westerberg wrote:
> On Fri, Jan 20, 2017 at 10:02:50AM +0200, Jani Nikula wrote:
>> That said, I suppose there could be an alternative to handling pwm_get()
>> failures at probe. We could just go on with our init, but schedule a
>> retry later. Perhaps a bit hacky, but it
On 2017.02.24 12:13:12 +0200, Jani Nikula wrote:
> On Fri, 24 Feb 2017, Zhenyu Wang wrote:
> > Hi,
> >
> > This pull includes latest GVT-g fixes for 4.11 to resolve stablity
> > and usability issues found during co-debugging with distribution
> > developers which improves a lot.
>
> I'll pull th
Hi,
On 08-03-17 10:40, Jani Nikula wrote:
On Fri, 20 Jan 2017, Mika Westerberg wrote:
On Fri, Jan 20, 2017 at 10:02:50AM +0200, Jani Nikula wrote:
That said, I suppose there could be an alternative to handling pwm_get()
failures at probe. We could just go on with our init, but schedule a
retr
On Wed, Mar 08, 2017 at 10:26:54AM +0200, Jani Nikula wrote:
> On Tue, 07 Mar 2017, Maxime Ripard wrote:
> > I just rebased my tree on top of the latest drm-misc tag
> > (drm-misc-next-2017-03-06). It should compile, and not have merge
> > conflicts anymore.
>
> Conflicts happen. Rebasing should
On Wed, Mar 08, 2017 at 08:25:12AM +, Tvrtko Ursulin wrote:
>
> On 07/03/2017 20:58, Chris Wilson wrote:
> >If we allow the user to convert a GTT mmap address into a userptr, we
> >may end up in recursion hell, where currently we hit a mutex deadlock
> >but other possibilities include use-afte
On Wed, Mar 08, 2017 at 02:19:48AM +0100, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> >Arkadiusz Hiler
> >Sent: Tuesday, March 7, 2017 7:25 AM
> >To: intel-gfx@lists.freedesktop.org
> >Subject: [Intel
On Wed, Mar 08, 2017 at 11:23:36AM +0200, Jani Nikula wrote:
> On Wed, 08 Mar 2017, "Srivatsa, Anusha" wrote:
> >>-Original Message-
> >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> >>Of
> >>Arkadiusz Hiler
> >>Sent: Tuesday, March 7, 2017 7:25 AM
> >>To: i
On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote:
> Hi Paul,
>
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/linux/resource_ext.h:19:0,
> from include/linux/pci.h:32,
>
On Wed, 08 Mar 2017, Hans de Goede wrote:
> Hi,
>
> On 08-03-17 10:40, Jani Nikula wrote:
>> On Fri, 20 Jan 2017, Mika Westerberg wrote:
>>> On Fri, Jan 20, 2017 at 10:02:50AM +0200, Jani Nikula wrote:
That said, I suppose there could be an alternative to handling pwm_get()
failures at
On Wed, Mar 08, 2017 at 10:19:39AM +0200, Jani Nikula wrote:
> On Tue, 07 Mar 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > printks are slow so we should not be doing them from the vblank evade
> > critical section. These could explain why we sometimes seem to
> > blow
On Wed, 08 Mar 2017, Zhenyu Wang wrote:
> On 2017.02.24 12:13:12 +0200, Jani Nikula wrote:
>> On Fri, 24 Feb 2017, Zhenyu Wang wrote:
>> > Hi,
>> >
>> > This pull includes latest GVT-g fixes for 4.11 to resolve stablity
>> > and usability issues found during co-debugging with distribution
>> > de
On Wed, 08 Mar 2017, Ville Syrjälä wrote:
> On Wed, Mar 08, 2017 at 10:19:39AM +0200, Jani Nikula wrote:
>> On Tue, 07 Mar 2017, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > printks are slow so we should not be doing them from the vblank evade
>> > critical section. The
If we allow the user to convert a GTT mmap address into a userptr, we
may end up in recursion hell, where currently we hit a mutex deadlock
but other possibilities include use-after-free during the
unbind/cancel_userptr.
[ 143.203989] gem_userptr_bli D0 902898 0x
[ 143.204054]
On Wed, Mar 08, 2017 at 12:20:53PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 08, 2017 at 10:19:39AM +0200, Jani Nikula wrote:
> > On Tue, 07 Mar 2017, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > printks are slow so we should not be doing them from the vblank evade
>
On Tue, Mar 07, 2017 at 10:32:14PM +, Chris Wilson wrote:
> On Tue, Mar 07, 2017 at 05:27:09PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
> > height down to 8 lines from the otherwise squ
Add gem_spin_batch to test that the dummyload infra
is working properly. Can be also act as tool to force
a single engine to be busy for controlled period of time.
v2: plenty of igt-fu improvements (Chris)
v3: nesting batches for more utilization, epsilon fun (Chris)
Cc: Abdiel Janulgue
Cc: Chri
On Tue, Mar 07, 2017 at 10:32:14PM +, Chris Wilson wrote:
> On Tue, Mar 07, 2017 at 05:27:09PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
> > height down to 8 lines from the otherwise squ
On Tue, Mar 07, 2017 at 10:24:21PM +, Chris Wilson wrote:
> On Tue, Mar 07, 2017 at 05:27:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The 845/865 and 830/855/9xx+ style cursor don't have that
> > much in common with each other, so let's just split the
> >
From: Tvrtko Ursulin
Given a log file created via perf with some interesting trace
events enabled, this tool can generate the timeline graph of
requests getting queued, their dependencies resolved, sent to
the GPU for executing and finally completed.
This can be useful when analyzing certain cla
On Wed, Mar 08, 2017 at 12:40:53PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 07, 2017 at 10:32:14PM +, Chris Wilson wrote:
> > On Tue, Mar 07, 2017 at 05:27:09PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > IVB introduced the CUR_FBC_CTL register whic
On Wed, Mar 08, 2017 at 12:44:06PM +0200, Mika Kuoppala wrote:
> Add gem_spin_batch to test that the dummyload infra
> is working properly. Can be also act as tool to force
> a single engine to be busy for controlled period of time.
>
> v2: plenty of igt-fu improvements (Chris)
> v3: nesting batch
On Wed, Mar 08, 2017 at 10:36:15AM +0100, Maarten Lankhorst wrote:
> Op 07-03-17 om 21:54 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > printks are slow so we should not be doing them from the vblank evade
> > critical section. These could explain why we sometimes seem to
On Wed, Mar 08, 2017 at 03:14:03PM -0500, bing@intel.com wrote:
> From: Bing Niu
>
> under virtualization enviroment, it is possible guest update pipe
> registers across vblank intervals due to overhead of mmio traps or vm
> schedule out. However, it is safe since those pipe update happen in
Chris Wilson writes:
> On Wed, Mar 08, 2017 at 12:44:06PM +0200, Mika Kuoppala wrote:
>> Add gem_spin_batch to test that the dummyload infra
>> is working properly. Can be also act as tool to force
>> a single engine to be busy for controlled period of time.
>>
>> v2: plenty of igt-fu improvemen
This reverts commit 77705ceb84161c9f5074200460fd6cb26b6a0f93.
With inflight request cancellation now used to track the broken
requests, we can restore the ability to unwedge the machine for igt.
Testcase: igt/gem_eio
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala flags))
Check the error of the fence upon submission and skip the request
(clearing out the dispatch and only processing the breadcrumb update) if
we are propagating an earlier failure. This means that we cancel
requests inflight without having to override the engine->submit_request
callback, eliminating t
In order to handle asynchronous error conditions, we need to store the
error status on the fence itself, and inspect it upon signaling.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_sw_fence.c | 25 -
Since commit 821ed7df6e2a ("drm/i915: Update reset path to fix
incomplete requests"), setting the device as wedged is permanent as we
cannot recover the engine->submit_request. Stop clearing the I915_WEDGED
status to prevent userspace can getting itself in a muddle.
To fix this correctly, we need
On Wed, Mar 08, 2017 at 11:40:07AM +, Chris Wilson wrote:
> Since commit 821ed7df6e2a ("drm/i915: Update reset path to fix
> incomplete requests"), setting the device as wedged is permanent as we
> cannot recover the engine->submit_request. Stop clearing the I915_WEDGED
> status to prevent user
On Wed, Mar 08, 2017 at 11:40:09AM +, Chris Wilson wrote:
> @@ -486,6 +503,10 @@ submit_notify(struct i915_sw_fence *fence, enum
> i915_sw_fence_notify state)
> switch (state) {
> case FENCE_COMPLETE:
> trace_i915_gem_request_submit(request);
> + if (unlik
Check the error of the fence upon submission and skip the request
(clearing out the dispatch and only processing the breadcrumb update) if
we are propagating an earlier failure. This means that we cancel
requests inflight without having to override the engine->submit_request
callback, eliminating t
Hey,
Op 07-02-17 om 14:33 schreef Mika Kahola:
> When doing a full atomic modeset, kernel should fail if the flag
> DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of
> 'kms_plane_lowres' testset. The testcases are 'pipe-x-allow-modeset' where
> x stands for pipe in question.
We can assume that if the device is asleep then all pending GTT writes
will have been posted, and so we can defer the flush from
i915_gem_object_flush_gtt_write_domain()
[ 1957.462568] WARNING: CPU: 0 PID: 6132 at
drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915]
[ 1957.4625
On 08/03/2017 10:01, Chris Wilson wrote:
On Wed, Mar 08, 2017 at 08:25:12AM +, Tvrtko Ursulin wrote:
On 07/03/2017 20:58, Chris Wilson wrote:
If we allow the user to convert a GTT mmap address into a userptr, we
may end up in recursion hell, where currently we hit a mutex deadlock
but oth
On Wed, Mar 08, 2017 at 01:04:29PM +, Tvrtko Ursulin wrote:
>
> On 08/03/2017 10:01, Chris Wilson wrote:
> >On Wed, Mar 08, 2017 at 08:25:12AM +, Tvrtko Ursulin wrote:
> >>
> >>On 07/03/2017 20:58, Chris Wilson wrote:
> >>>If we allow the user to convert a GTT mmap address into a userptr,
On 08/03/2017 13:10, Chris Wilson wrote:
On Wed, Mar 08, 2017 at 01:04:29PM +, Tvrtko Ursulin wrote:
On 08/03/2017 10:01, Chris Wilson wrote:
On Wed, Mar 08, 2017 at 08:25:12AM +, Tvrtko Ursulin wrote:
On 07/03/2017 20:58, Chris Wilson wrote:
If we allow the user to convert a GTT m
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/userptr: Deactivate a failed
userptr if the worker reports an EFAULT (rev2)
URL : https://patchwork.freedesktop.org/series/20855/
State : success
== Summary ==
Series 20855v2 Series without cover letter
https://patchwork.free
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Re
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashan
We have to avoid taking ww_mutex inside the shrinker as we use it as a
plain mutex type and so need to avoid recursive deadlocks:
[ 602.771969] =
[ 602.771970] [ INFO: inconsistent lock state ]
[ 602.771973] 4.10.0gpudebug+ #122 Not tainted
[ 602.771974] ---
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modese
i915_gem_object_is_dead() was a temporary lockdep aide whilst
transitioning to a new locking structure for obj->mm. Since commit
1233e2db199d ("drm/i915: Move object backing storage manipulation to its
own locking") it is now unused and should be removed.
Signed-off-by: Chris Wilson
Cc: Joonas La
On 08/03/2017 10:33, Chris Wilson wrote:
If we allow the user to convert a GTT mmap address into a userptr, we
may end up in recursion hell, where currently we hit a mutex deadlock
but other possibilities include use-after-free during the
unbind/cancel_userptr.
[ 143.203989] gem_userptr_bli D
Some frame sources such as sinks aren't able to provide meaningful frame
numbers, so in those cases just skip the TEST_SEQUENCE tests.
Signed-off-by: Tomeu Vizoso
---
tests/kms_pipe_crc_basic.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/tes
When opening a DRM debugfs file, locate the right path based on the
given DRM device FD.
This is needed so, in setups with more than one DRM device, any
operations on debugfs files affect the expected DRM device.
Signed-off-by: Tomeu Vizoso
---
Guess we could be more conservative and just rena
Chris Wilson writes:
> Currently, we sum the render and media cycles (on different engines) to
> compute a percentage - but we fail to factor in the duplication into the
> threshold calculations. This makes us very eager to upclock!
>
I wonder if this was intentional. However acting on behalf
of
Hi,
On 08-03-17 11:15, Jani Nikula wrote:
On Wed, 08 Mar 2017, Hans de Goede wrote:
Hi,
On 08-03-17 10:40, Jani Nikula wrote:
On Fri, 20 Jan 2017, Mika Westerberg wrote:
On Fri, Jan 20, 2017 at 10:02:50AM +0200, Jani Nikula wrote:
That said, I suppose there could be an alternative to hand
On Wed, 2017-03-08 at 13:38 +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 07-02-17 om 14:33 schreef Mika Kahola:
> >
> > When doing a full atomic modeset, kernel should fail if the flag
> > DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as
> > part of
> > 'kms_plane_lowres' testset
On Wed, Mar 08, 2017 at 01:28:31PM +, Tvrtko Ursulin wrote:
>
> On 08/03/2017 10:33, Chris Wilson wrote:
> >If we allow the user to convert a GTT mmap address into a userptr, we
> >may end up in recursion hell, where currently we hit a mutex deadlock
> >but other possibilities include use-afte
== Series Details ==
Series: drm/i915: CCS prep stuff
URL : https://patchwork.freedesktop.org/series/20851/
State : failure
== Summary ==
Series 20851v1 drm/i915: CCS prep stuff
https://patchwork.freedesktop.org/api/1.0/series/20851/revisions/1/mbox/
Test gem_exec_flush:
Subgroup basi
On Wed, Mar 08, 2017 at 03:40:52PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Currently, we sum the render and media cycles (on different engines) to
> > compute a percentage - but we fail to factor in the duplication into the
> > threshold calculations. This makes us very eager to
Op 23-02-17 om 14:26 schreef Mika Kahola:
> This test case introduces concurrently running test cases for atomic
> modesetting.
>
> The first test or thread draws blue backround with black holes on it.
> These holes are covered by rectangular, blue planes that are placed
> randomly like in test cas
Op 08-03-17 om 14:45 schreef Mika Kahola:
> On Wed, 2017-03-08 at 13:38 +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 07-02-17 om 14:33 schreef Mika Kahola:
>>> When doing a full atomic modeset, kernel should fail if the flag
>>> DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as
>
On Wed, Mar 08, 2017 at 01:52:09PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: CCS prep stuff
> URL : https://patchwork.freedesktop.org/series/20851/
> State : failure
>
> == Summary ==
>
> Series 20851v1 drm/i915: CCS prep stuff
> https://patchwork.freedesktop.org/api
Op 17-02-17 om 14:39 schreef Mika Kahola:
> We need to make sure that TEST_ONLY really only touches the free-standing
> state objects and nothing else. Test approach here is the following:
>
> - Create a config and submit it with TEST_ONLY.
> - do dpms off/on cycle with the current config to reconf
On Wed, Mar 08, 2017 at 04:08:05PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 08, 2017 at 01:52:09PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: CCS prep stuff
> > URL : https://patchwork.freedesktop.org/series/20851/
> > State : failure
> >
> > == Summary ==
> >
At least radeon, amdgpu and nouveau should be converted. We have
patches for i915 already.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index ce0f1a588e7f..63
Hi all,
So I looked at drmP.h, thought "this is small, should finally be doable to split
it all into sensible pieces and document things".
Yes that joke was on me, only managed to do a few random things and then split
out drm_file related things. Plus clean those up and give the docs a fresh-up.
And remove the semi-kernel-doc stuff, to make sure no one uses this.
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 15 ---
include/drm/drm_auth.h | 17 +
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP
Plus a little bit more documentation.
v2: Untangle the missing forward decls to make drm_prime|gem.h
free-standing.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-mm.rst | 3 ++
drivers/gpu/drm/drm_prime.c | 3 +-
include/drm/drmP.h| 32 ++
include/drm/d
An easy one as a drive-by.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_kms_helper_common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index 45db36cd3d20..6e35a56a6102 100644
---
It's not just file ops, but drm_file stuff in general. This is prep
work to extracting a drm_file.h header in the next patch.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-internals.rst| 4 ++--
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/{drm_fops.c => dr
This was originally added by David Herrmann for range checks, but
entirely unused. It confused me, so let's remove it.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 82610178
I'm torn on whether drm_minor really should be here or somewhere else.
Maybe with more clarity after untangling drmP.h more this is easier to
decide, for now I've put a FIXME comment right next to it. Right now
we need struct drm_minor for the inline drm_file type helpers, and so
it does kinda make
We might as well dump the drm_file pointer, that's about as useful
a cookie as the pid. Noticed while typing docs for drm_file and friends.
Since the only consumer of this is the tracepoints I think we can safely
change this - those tracepoints should not be uapi relevant at all. It
all goes back
Worst case if the hw can't support completion signalling in a
race-free way we want the event to be too late, not too early.
Text adapted from a proposal from Laurent - the other side of how to
make hw work correctly where it's possible is imo already sufficiently
documented.
v2: Review from Laur
Well, mostly drm_file.h, and clean up all related things:
- I didnt' figure out the difference between preclose and postclose.
The existing explanation in drm-internals.rst didn't convince me,
since it's also really outdated - we clean up pending DRM events in
the core nowadays. I put a FIXM
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/rad
There's really not a reason afaics that we can't just clean up
everything at the end, in the terminal postclose hook: Since this is
closing a file descriptor we know no one else can have a reference or
a thread doing something with that drm_file except the close code.
Ordering shouldn't matter, as
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 4 ++--
1 file changed, 2
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +--
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm
The core takes care of handling the send_event vs. close() issues, we
can remove that driver code.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 12 +++-
drivers/gpu/drm/msm
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Alex Deucher
Cc: Christian König
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu
I didn't spot anything that would require ordering here (well not
anywhere else either), and I'm trying to unify at least modern drivers
on one close hook.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/ms
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exyn
Less code ftw.
This converts all drivers except the tinydrm helper module. That one
needs more work, since it gets the THIS_MODULE reference from
tinydrm.ko instead of the actual driver module like it should.
Probably needs a similar trick like I used here with generating the
entire struct with a
Just another step in finally making drmP.h obsolete.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 7 +
include/drm/drmP.h| 43 +++---
include/drm/drm_pci.h | 78 +++
3 files changed, 89 insertions(+)
With all drivers converted there's only legacy dri1 drivers using it.
Not going to touch those, instead just hide it like we've done with
other dri1 driver hooks like firstopen.
In all this I didn't find any real reason why we'd needed 2 hooks, and
having symmetry between open and close just appea
Sadly there's only 1 driver which can use it, everyone else is special
for some reason:
- gma500 has a horrible runtime PM ioctl wrapper that probably doesn't
really work but meh.
- i915 needs special compat_ioctl handler because regrets.
- arcgpu needs to fixup the pgprot because (no idea why i
Hi
On Wed, Mar 8, 2017 at 3:12 PM, Daniel Vetter wrote:
> This was originally added by David Herrmann for range checks, but
> entirely unused. It confused me, so let's remove it.
>
> Cc: David Herrmann
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drmP.h | 1 -
> 1 file changed, 1 deletio
1 - 100 of 183 matches
Mail list logo
