On 14 October 2015 at 19:52, Chris Wilson wrote:
> If we need to take the error path and drop the references to the objects
> and handle we created earlier, there is a possibility that we then free
> the object and then attempt to free any associated PRIME resources under
> the prime mutex. If we
The first two patches are cleanups, the second two attempt
to fix the deadlock on the prime lock, in the failure paths.
Patch 3 is based on a proposal from Daniel Vetter.
I've ran these under virgl and I can't reproduce the deadlock
there.
Dave.
From: Dave Airlie
This code was duplicated, make it decidely
less duplicated.
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c
From: Dave Airlie
I think I might have been responsible for some of this, but it's messy
to decode, this doesn't change anything, but cleans up the goto's
and exit paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_prime.c | 73 -
1 file chang
From: Dave Airlie
This patch cleans up one locking order issue with a deadlock on
the prime lock.
It avoids calling the prime delete function from drm_gem_handle_create_tail,
and instead open codes the exit paths, it also splits the common code
out for the exit path which can use it.
This means
From: Dave Airlie
calling drm_gem_handle_delete would cause an attempt to retake
the prime lock.
move code around so we never need to do that. This patch allocates
the member structure early, so there is no failure path that
requires calling drm_gem_handle_delete.
Signed-off-by: Dave Airlie
--
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_irq.c
between commit:
fd8f507c0de9 ("drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.")
from the drm-intel tree and commit:
88e72717c2de ("drm/irq: Use unsigned int pipe in public AP
On 15.10.2015 04:26, Alex Deucher wrote:
> From: Michel Dänzer
>
> This fixes flickering issues caused by prematurely firing pflip
> interrupts.
>
> v2 (chk): add commit message, fix DCE V10/V11 and DM as well
> v3: Re-enable pflip interrupt wherever we re-enable a CRTC
> v4: Enable pflip inter
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/9558fb43/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105051
Felipe Ortiz changed:
What|Removed |Added
CC||fortizc at gmail.com
--- Comment #14 from
Fixes compiler error:
drm/savage_drm.h:50:24: error: array type has incomplete element type
struct drm_tex_region texList[SAVAGE_NR_TEX_HEAPS][SAVAGE_NR_TEX_REGIONS +
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/savage_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/ua
On Wed, Oct 14, 2015 at 09:51:13PM -0700, Darren Hart wrote:
> On Fri, Aug 14, 2015 at 06:18:55PM +0200, Lukas Wunner wrote:
> > Originally by Seth Forshee , 2012-10-04:
> > The gmux allows muxing the DDC independently from the display, so
> > support this functionality. This will allow rea
Fixes userspace compile error since list_head is not exported to userspace
headers.
Suggested by Emil Velikov at
https://lkml.org/lkml/2015/6/3/792
Signed-off-by: Mikko Rapeli
---
drivers/gpu/drm/via/via_drv.h | 4
include/uapi/drm/via_drm.h| 4
2 files changed, 4 insertions(+),
On Thu, Oct 15, 2015 at 11:51:39AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> I think I might have been responsible for some of this, but it's messy
> to decode, this doesn't change anything, but cleans up the goto's
> and exit paths.
>
> Signed-off-by: Dave Airlie
Before coffee, but lo
On Thu, Oct 15, 2015 at 11:51:40AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This patch cleans up one locking order issue with a deadlock on
> the prime lock.
>
> It avoids calling the prime delete function from drm_gem_handle_create_tail,
> and instead open codes the exit paths, it also
Fixes compile error:
drm/r128_drm.h:156:23: error: array type has incomplete element type
struct drm_clip_rect boxes[R128_NR_SAREA_CLIPRECTS];
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/r128_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/r128_drm.h b/includ
Fixes userspace compile error:
drm/sis_drm.h:68:19: error: field âobj_listâ has incomplete type
struct list_head obj_list;
Suggested by Emil Velikov at
https://lkml.org/lkml/2015/6/3/792
Signed-off-by: Mikko Rapeli
---
drivers/gpu/drm/sis/sis_drv.h | 4
include/uapi/drm/sis_drm.h
On Thu, Oct 15, 2015 at 11:51:41AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> calling drm_gem_handle_delete would cause an attempt to retake
> the prime lock.
>
> move code around so we never need to do that. This patch allocates
> the member structure early, so there is no failure path t
On Thu, Oct 15, 2015 at 07:55:49AM +0200, Mikko Rapeli wrote:
> Fixes compiler error:
>
> drm/savage_drm.h:50:24: error: array type has incomplete element type
> struct drm_tex_region texList[SAVAGE_NR_TEX_HEAPS][SAVAGE_NR_TEX_REGIONS +
>
> Signed-off-by: Mikko Rapeli
Queued for -next, thanks
Fixes userspace compilation errors like:
drm/nouveau_drm.h:41:2: error: unknown type name âuint32_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/nouveau_drm.h | 86 +-
1 file changed, 44 insertions(+), 42 deletions(-)
diff --git a/include/uapi/d
On Wed, Jun 03, 2015 at 06:19:48PM +0100, Emil Velikov wrote:
> On 30 May 2015 at 16:37, Mikko Rapeli wrote:
> > Fixes userspace compilation error:
> >
> > drm/drm.h:132:2: error: unknown type name âsize_tâ
> >
> > Signed-off-by: Mikko Rapeli
> > ---
> > include/uapi/drm/drm.h | 8
>
Fixes userspace compilation error:
drm/drm_mode.h:472:2: error: unknown type name âuint32_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/drm_mode.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mo
Fixes userspace compilation errors like:
error: unknown type name âuint32_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/qxl_drm.h | 74 +++---
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/include/uapi/drm/qxl_drm.h b/include/u
Fixes userspace compilation error:
drm/exynos_drm.h:30:2: error: unknown type name âuint64_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/exynos_drm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
Fixes userspace compilation error:
error: array type has incomplete element type
struct drm_clip_rect boxes[I810_NR_SAREA_CLIPRECTS];
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/i810_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/
Fixes userspace compiler error:
drm/radeon_drm.h:794:2: error: unknown type name âuint64_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/radeon_drm.h | 128 +-
1 file changed, 64 insertions(+), 64 deletions(-)
diff --git a/include/uapi/drm/radeon
Fall back to size_t for non Linux platforms.
Fixes userspace compilation error:
drm/drm.h:132:2: error: unknown type name âsize_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/drm.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/drm.h b/in
Fixes userspace compilation errors like:
error: unknown type name âuint32_tâ
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/vmwgfx_drm.h | 264 +-
1 file changed, 132 insertions(+), 132 deletions(-)
diff --git a/include/uapi/drm/vmwgfx_drm.h b/incl
Fixes compiler error:
drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory
Signed-off-by: Mikko Rapeli
---
include/uapi/drm/via_drm.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h
index 8b0533c..d19c0e2 1006
On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote:
> > Yet the rc-cec is a module in the filesystem, but it doesn't seem to
> > be loaded automatically - even after the system has booted, the module
> > hasn't been loaded.
> >
> > It looks like it _should_ be loaded, but this plainly is
Hi all,
So I hoped to get through more drivers, but it's not yet all of them. Anyway,
this gets rid of dev->struct_mutex in a lot more places. Big thing is that core
gem is now completely struct_mutex free, the only reason we still lock it is
that some drivers need it in their ->free_gem_object ho
We need to drop the gem bo reference if it's an imported one.
Cc: Russell King
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
in
Reusing the Big DRM Lock just leaks, and the few things left that
dev->struct_mutex protected are very well contained - it's just the
linear drm_mm manager.
With this armada is completely struct_mutex free!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_debugfs.c | 4 ++--
driv
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
v2: Split out the leak fix in dump_map_offset into
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
While at it also fix a leak when this ioctl is call
The kms state itself is already protected by the modeset locks
acquired by the drm core. The only thing left is gem bo state, and
since the cursor code expects small objects which are statically
mapped at create time and then invariant over the lifetime of the gem
bo there's nothing to protect.
Se
It's duplicating (without using some of the helpers) drm_gem_mmap with
the addition that it can redirect to drm-buf mmap support. But prime
import/export was dropped in
commit 990ed2720717173bbdea4cfb2bad37cc7aa91495
Author: Rob Clark
Date: Thu May 21 11:58:30 2015 -0400
drm/vgem: drop DRI
Pretty soon only some drivers will need dev->struct_mutex in their
gem_free_object callbacks. Hence it's really important to make sure
everything still keeps getting this right.
Signed-off-by: Daniel Vetter
---
include/drm/drm_gem.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/d
This only grabs the mutex when really needed, but still has a
might-acquire lockdep check to make sure that's always possible.
With this patch tegra is officially struct_mutex free, yay!
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 4 +---
drivers/gpu/drm/te
Since
commit 131e663bd6f1055caaff128f9aa5071d227eeb72
Author: Daniel Vetter
Date: Thu Jul 9 23:32:33 2015 +0200
drm/gem: rip out drm vma accounting for gem mmaps
there is no need for this any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 4
d
This is called without dev->struct_mutex held, we need to use the
_unlocked variant.
Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/gem.c | 2 +-
1 file changed, 1
Just a random thing I spotted while reading code - better safe than
sorry.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 7dc4a8a066a3..ab8ea42264f4 10064
Compared to wrapping the final kref_put with dev->struct_mutex this
allows us to only acquire the offset manager look both in the final
cleanup and in the lookup. Which has the upside that no locks leak out
of the core abstractions.
Also, this is the final bit which required dev->struct_mutex in g
It's either init code or already protected by other means. Note
that psb_gtt_pin/unpin has it's own lock, and that's really the
only piece of driver private state - all the modeset state is
protected with modeset locks already.
The only important bit is to switch all gem_obj_unref calls to the
_un
This is init/teardown code, locking is just to appease locking checks.
And since gem create/free doesn't need this any more there's really no
reason for grabbing dev->struct_mutex.
Again important to switch obj_unref to _unlocked variants.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500
Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/gem.c | 13 +++--
1 file changed,
There's currently two places where the gma500 fault handler relies
upon dev->struct_mutex:
- To protect r->mappping
- To make sure vm_insert_pfn isn't called concurrently (in which case
the 2nd thread would get an error code).
Everything else (specifically psb_gtt_pin) is already protected by
so
Doesn't protect anything at all.
With this patch nouveau is completely dev->struct_mutex free!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouv
This removes the last depency of radeon for dev->struct_mutex!
Also the locking scheme for hyperz/cmask owners seems a bit unsound,
there's no protection in the preclose handler (and that never did hold
dev->struct_mutex while being called). So grab the same lock there,
too.
There's also all the
The sg table isn't refcounted, there's no corresponding locking for
unmapping and drm_map_sg is ok with being called concurrently.
So drop the locking since it doesn't protect anything.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 4
1 file changed, 4 deletion
Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.
Aside: DRM_ERROR for userspace controlled input isn't great, but
that's for another patch.
Signed-
With the previous two changes it doesn't protect anything any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 1a60934
The only things this protects is reading ->flags and ->size, both of
which are invariant over the lifetime of an exynos gem bo. So no
locking needed at all (besides that, nothing protects the writers
anyway).
Aside: exynos_gem_obj->size is redundant with
exynos_gem_obj->base.size and probably shou
Doesn't protect anything at all, and probably just here because a long
time ago dev->struct_mutex was required to allocate gem objects.
With this patch exynos is completely struct_mutex free!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 --
vgem doesn't have a shrinker or anything like that and drops backing
storage only at object_free time. There's no use in trying to be
clever and allocating backing storage delayed, it only causes trouble
by requiring locking.
Instead grab pages when we allocate the object right away.
Signed-off-b
The offset manager already checks for existing offsets internally,
while holding suitable locks. We can drop this check.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/
On Thu, Oct 15, 2015 at 07:55:46AM +0200, Mikko Rapeli wrote:
> Fixes compile error:
>
> drm/r128_drm.h:156:23: error: array type has incomplete element type
> struct drm_clip_rect boxes[R128_NR_SAREA_CLIPRECTS];
>
> Signed-off-by: Mikko Rapeli
Applied to drm-misc, thanks.
-Daniel
> ---
> i
On Thu, Oct 15, 2015 at 07:55:51AM +0200, Mikko Rapeli wrote:
> Fixes userspace compilation error:
>
> error: array type has incomplete element type
> struct drm_clip_rect boxes[I810_NR_SAREA_CLIPRECTS];
>
> Signed-off-by: Mikko Rapeli
Applied to drm-misc, thanks.
-Daniel
> ---
> include/uapi
Don't forget https://bugs.freedesktop.org/attachment.cgi?id=118844
"drm/amdgpu: adjust default dispclk (v2)"
Regards
//Ernst
2015-10-14 22:44 GMT+02:00 Alex Deucher :
> Hi Dave,
>
> This is the first radeon and amdgpu pull for drm-next. Highlights include:
> - Efficiency improvements to the CS
On 15.10.2015 09:36, Daniel Vetter wrote:
> This removes the last depency of radeon for dev->struct_mutex!
>
> Also the locking scheme for hyperz/cmask owners seems a bit unsound,
> there's no protection in the preclose handler (and that never did hold
> dev->struct_mutex while being called). So gr
Hi
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> Since
>
> commit 131e663bd6f1055caaff128f9aa5071d227eeb72
> Author: Daniel Vetter
> Date: Thu Jul 9 23:32:33 2015 +0200
>
> drm/gem: rip out drm vma accounting for gem mmaps
>
> there is no need for this any more.
>
> Signed-off-b
Hi
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> Pretty soon only some drivers will need dev->struct_mutex in their
> gem_free_object callbacks. Hence it's really important to make sure
> everything still keeps getting this right.
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/
Hi
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> Just a random thing I spotted while reading code - better safe than
> sorry.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/gpu/drm/drm_gem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1
Hi
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> Compared to wrapping the final kref_put with dev->struct_mutex this
> allows us to only acquire the offset manager look both in the final
> cleanup and in the lookup. Which has the upside that no locks leak out
> of the core abstractions
On Thu, Oct 15, 2015 at 10:36:08AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
> wrote:
> > Pretty soon only some drivers will need dev->struct_mutex in their
> > gem_free_object callbacks. Hence it's really important to make sure
> > everything still kee
Hi
On Thu, Oct 15, 2015 at 10:55 AM, Daniel Vetter wrote:
> On Thu, Oct 15, 2015 at 10:36:08AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
>> wrote:
>> > Pretty soon only some drivers will need dev->struct_mutex in their
>> > gem_free_object callbacks
Compared to wrapping the final kref_put with dev->struct_mutex this
allows us to only acquire the offset manager look both in the final
cleanup and in the lookup. Which has the upside that no locks leak out
of the core abstractions. But it means that we need to hold a
temporary reference to the obj
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/08ee3194/attachment.html>
On Thu, Oct 15, 2015 at 11:33:43AM +0200, Daniel Vetter wrote:
> Compared to wrapping the final kref_put with dev->struct_mutex this
> allows us to only acquire the offset manager look both in the final
> cleanup and in the lookup. Which has the upside that no locks leak out
> of the core abstracti
On Thu, Oct 15, 2015 at 11:06:59AM +0100, Chris Wilson wrote:
> On Thu, Oct 15, 2015 at 11:33:43AM +0200, Daniel Vetter wrote:
> > Compared to wrapping the final kref_put with dev->struct_mutex this
> > allows us to only acquire the offset manager look both in the final
> > cleanup and in the looku
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/2f52ae2f/attachment.html>
On Thu, Oct 15, 2015 at 01:11:36PM +0200, Daniel Vetter wrote:
> On Thu, Oct 15, 2015 at 11:06:59AM +0100, Chris Wilson wrote:
> > On Thu, Oct 15, 2015 at 11:33:43AM +0200, Daniel Vetter wrote:
> > > Compared to wrapping the final kref_put with dev->struct_mutex this
> > > allows us to only acquire
In its original version, drm_framebuffer_init() returned a negative int
if drm_mode_object_get() failed (f453ba046074, "DRM: add mode setting
support").
This was accidentally disabled by commit 4b096ac10da0 ("drm: revamp
locking around fb creation/destruction"). Thus, drm_framebuffer_init()
preten
Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
v2: Finally get rid of the copypasta from another c
On Thu, Oct 15, 2015 at 2:35 PM, Daniel Vetter
wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm core st
On of_init(), we store the size given by the openfirmware in bios->size,
this allows to remove of_size that is only used by openfirmware interface.
As bios->size is the size of available data in bios->data, we must
copy all data to bios->data.
Tested on PowerMac G5 with 64bit kernel and a NV43 car
Hi,
this second pull request replaces the last references to device_initcall_sync
with late_initcall, as noticed by Frank Rowand.
Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.
Thanks,
Tomeu
The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> This is called without dev->struct_mutex held, we need to use the
> _unlocked variant.
>
> Never caught in the wild since you'd need an evil userspace which
> races a gem_close ioctl call with the in-progress open.
>
> Signed-off-by: Daniel
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> It's either init code or already protected by other means. Note
> that psb_gtt_pin/unpin has it's own lock, and that's really the
> only piece of driver private state - all the modeset state is
> protected with modeset locks already.
>
> The
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> This is init/teardown code, locking is just to appease locking checks.
> And since gem create/free doesn't need this any more there's really no
> reason for grabbing dev->struct_mutex.
>
> Again important to switch obj_unref to _unlocked var
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/e8a18a3b/attachment.html>
On Thu, Oct 15, 2015 at 11:56:56AM +0200, Lukas Wunner wrote:
> In its original version, drm_framebuffer_init() returned a negative int
> if drm_mode_object_get() failed (f453ba046074, "DRM: add mode setting
> support").
>
> This was accidentally disabled by commit 4b096ac10da0 ("drm: revamp
> loc
On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli wrote:
> Fixes userspace compilation error:
>
> drm/drm_mode.h:472:2: error: unknown type name âuint32_tâ
>
> Signed-off-by: Mikko Rapeli
NACK on all these type conversions. This has not been a problem for
years and years and the result looks te
This worked before the dw-hdmi bridge code was changed to validate
the setup data more strictly. Add back support for modes with a
pixel clock up to 216MHz. Even higher clocks should work, but we
are missing the required setup data for now.
Also change the mode validate callbacks to disallow modes
https://bugzilla.kernel.org/show_bug.cgi?id=104881
--- Comment #3 from Jeff Nelson ---
Before creation of this issue, I found a similar, almost identical, issue on
the freedesktop bugzilla. Found here:
https://bugs.freedesktop.org/show_bug.cgi?id=91896
A possible bug was disovered on comment 13:
On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli wrote:
> > Fixes userspace compilation error:
> >
> > drm/drm_mode.h:472:2: error: unknown type name âuint32_tâ
> >
> > Signed-off-by: Mikko Rapeli
>
> NACK on all these type convers
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/04c75995/attachment.html>
From: Ville Syrjälä
Pull the crtc->invert_dimensions setting from omapdrm into the atomic
helpers so that all drivers will check viewport correctly in setcrtc()
after rotating the primary plane,
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 8
drivers/gpu/
From: Ville Syrjälä
When converting the mode hdisplay/vdisplay to primary plane src
coordinates we need to take into account the current plane
rotation.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
Hi Dave,
Just two fixes for amdgpu:
- fix pageflip interrupt issue
- fix display clock handling on certain fiji boards
The following changes since commit 7b98040a7718663903bb25c06c7aed9801abbd9d:
Merge branch 'linux-4.3' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2
On Thu, Oct 15, 2015 at 4:06 AM, Ernst Sjöstrand wrote:
> Don't forget https://bugs.freedesktop.org/attachment.cgi?id=118844
>
> "drm/amdgpu: adjust default dispclk (v2)"
That's going in as a fix for 4.3.
Alex
>
> Regards
> //Ernst
>
>
> 2015-10-14 22:44 GMT+02:00 Alex Deucher :
>> Hi Dave,
>>
On Thu, Oct 15, 2015 at 4:27 AM, Christian König
wrote:
> On 15.10.2015 09:36, Daniel Vetter wrote:
>>
>> This removes the last depency of radeon for dev->struct_mutex!
>>
>> Also the locking scheme for hyperz/cmask owners seems a bit unsound,
>> there's no protection in the preclose handler (and
On Thu, Oct 15, 2015 at 04:53:00PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Pull the crtc->invert_dimensions setting from omapdrm into the atomic
> helpers so that all drivers will check viewport correctly in setcrtc()
> after rotating the primary plane,
>
> Si
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/fc589430/attachment.html>
A few drivers in drivers/gpu/drm are component-enabled and use quite similar
code sequences to probe for their encoder slaves at the remote end of the ports.
Move the code into a "generic" function and remove it from the drivers.
The end results is that drivers get a reference count fix (imx), mor
The generic function is functionally equivalent to the driver's
imx_drm_platform_probe(). Use the generic function and reduce the
overall code size.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/imx/imx-drm-core.c | 54 +-
1 file changed, 1 insertion(+), 53 d
Use the generic drm_of_component_probe() function to probe for components.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 84 ++---
1 file changed, 5 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/
The armada DRM driver keeps some old platform data compatibility in the
probe function that makes moving to the generic drm_of_component_probe()
a bit more complicated that it should. Refactor the probe function to do
the platform_data processing after the generic probe (and if that fails).
This wa
A lot of component based DRM drivers use a variant of the same code
as the probe function. They bind the crtc ports in the first iteration
and then scan through the child nodes and bind the encoders attached
to the remote endpoints. Factor the common code into a separate
function called drm_of_comp
David,
Please incorporate the latest Synopsis DesignWare HDMI driver development
updates, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-dwhdmi-devel
with SHA1 dfbdaf50460479446a258ef781683e7d7d6349d7.
This series:
* adds support for interlaced video modes to the ipu
1 - 100 of 122 matches
Mail list logo
