Hi all,
The X.Org board is solicting further proposals to organize XDC
somewhere in Europe. The board has already received a proposal for
Helsinki and plans to vote on that in the next meeting on the 29th
Oct, but if there is anyone else interested in hosting XDC we'd very
much like to hear about
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/582aa3b8/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/aaf1aa84/attachment-0001.html>
rom
http://lists.freedesktop.org/archives/dri-devel/2015-October/092465.html is
applied.
Anyhow, I hope this patch is helpful.
Adam
--
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/6c6787a2/attachment.html>
Hi Daniel,
just triggered the below, this time on the Intel box. Maybe related to
the locking fun from a couple weeks ago?
I'm doing
$ powertop --auto-tune
---
...
[5.118418] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts:
(null)
[5.209310] EXT4-fs (sda4): mounted fil
gpu/drm/drm_dp_mst_topology.c
--
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/96273fb8/attachment.html>
bmission upstream.
Thanks in advance for any feedback on this.
--
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/8a8aa1db/attachment.html>
From: Ville Syrjälä
Instead of relying on the old crtc-{x,y,mode} gunk, dig out the primary
plane coordinates from the plane state when checking them against the
new framebuffer during page flip.
Cc: Matt Roper
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
driver
From: Ville Syrjälä
On atomic drivers we can dig out the primary plane rotation from the
plane state instead of looking at the legacy crtc->invert_dimensions
flag. The flag is not set by anyone except omapdrm, and it would be
racy to set it the same way in the atomic helpers.
Cc: Matt Roper
C
From: Ville Syrjälä
Pull the plane src coordinate checks into a separate function so that we
can share them for the legacy and new stuff.
Cc: Matt Roper
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 59 +++-
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.
Cc: Matt Roper
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++--
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7c8422..66233a8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/
Hi Daniel,
On Tue, Oct 13, 2015 at 09:28:13AM +0200, Daniel Vetter wrote:
> On Mon, Oct 12, 2015 at 12:09:53PM -0400, Alex Deucher wrote:
> > On Fri, Aug 28, 2015 at 7:30 AM, Lukas Wunner wrote:
> > > Signed-off-by: Lukas Wunner
> > Reviewed-by: Alex Deucher
>
> Merged the 3 cleanup patches to
On 10/15/2015 07:34 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 14, 2015 at 08:29:44AM +0200, Hans Verkuil wrote:
>> On 10/14/2015 12:51 AM, Russell King - ARM Linux wrote:
>>> On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
On 10/06/2015 07:06 PM, Russell King - ARM Linux
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter
wrote:
> 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
+1
On Wed, Oct 14, 2015 at 08:29:44AM +0200, Hans Verkuil wrote:
> On 10/14/2015 12:51 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
> >> On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> >>> Surely you aren't proposing that drivers shoul
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/9fffb1ec/attachment-0001.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/e4da3a08/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/b9d8104c/attachment.html>
On Thu, Oct 15, 2015 at 08:40:01PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> On atomic drivers we can dig out the primary plane rotation from the
> plane state instead of looking at the legacy crtc->invert_dimensions
> flag. The flag is not set by anyone except o
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
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
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 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
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
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
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
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/
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
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>
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
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 13/10/2015 at 11:55:42 +0200, Boris Brezillon wrote :
> Add myself as the maintainer of the atmel-hlcdc DRM driver.
>
> Signed-off-by: Boris Brezillon
> Acked-by: Nicolas Ferre
Acked-by: Alexandre Belloni
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
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
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 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 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
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 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
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/04c75995/attachment.html>
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:
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
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/e8a18a3b/attachment.html>
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
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 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
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
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
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
--
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
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 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
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.
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
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151015/2f52ae2f/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
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
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 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
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:
> 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:
> 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
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
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 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,
>>
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
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
Dave,
A single critical fix for a NULL pointer dereference regression
The following changes since commit 575f9c8604e0b4c7b36fb41fc5fd280a3c336906:
drm/vmwgfx: Fix a command submission hang regression (2015-09-30 05:50:37
-0700)
are available in the git repository at:
git://people.freedes
-
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 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
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
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
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/
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 --
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
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-
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
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
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
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,
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
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 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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
1 - 100 of 122 matches
Mail list logo
