https://bugzilla.kernel.org/show_bug.cgi?id=52491
--- Comment #2 from Bruno J. 2013-01-10 23:00:51 ---
Still happening in rc3
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the
mime type||
--
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/20130110/09c2a755/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/0bd551a8/attachment-0001.html>
On Thu, 10 Jan 2013 21:47:53 +0100
Daniel Vetter wrote:
> Only two places:
> - suspend/resume
> - Some really strange mode validation tool with too much funny-lucking
> hand-rolled conversion code.
> - The recently-added lastclose fbdev restore code.
>
> Better safe than sorry, so convert both
Hi Jesse
On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes
wrote:
> On Fri, 28 Sep 2012 23:44:18 +0200
> David Herrmann wrote:
>
>> Hi
>>
>> This is revision 2 of the manpages for libdrm. I converted everything to
>> docbook
>> XML. This makes it easier to write them (troff is really hard to read)
Hi Linus,
Just intel fixes, including getting the Ironlake systems back to the state
they were in for 3.6.
Dave.
The following changes since commit ecf02a607bd801e742d7bb35c6e40f7ca15edf03:
Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86
(2013-01-10 09:09:41 -0800
On Thu, Jan 10, 2013 at 9:48 PM, Daniel Vetter
wrote:
> Otherwise it seems like we can get stuck with concurrent waiters.
> Right now this /shouldn't/ be a problem, since all pending pageflip
> waiters are serialized by the one mode_config.mutex, so there's at
> most on waiter. But better paranoi
Otherwise it seems like we can get stuck with concurrent waiters.
Right now this /shouldn't/ be a problem, since all pending pageflip
waiters are serialized by the one mode_config.mutex, so there's at
most on waiter. But better paranoid than sorry, since this is tricky
code.
v2: WARN_ON(waitqueue_
We need to make sure that the fbcon is still bound when touching the
hw, since otherwise we might corrupt the modeset state of kms clients.
X mostly works around that with VT switching and setting the VT into
raw mode, which disables most fbcon events.
Raw kms test programs though don't do that da
Now that framebuffer are reference-counted for all use-sites, update
the documentation accordingly to stress the new rules for
initialization and teardown.
Also add a short paragraph about the implications for drivers of the
new locking rules.
Signed-off-by: Daniel Vetter
---
Documentation/DocB
The coup de grace of the entire journey. No more dropped frames every
10s on my testbox!
I've tried to audit all ->detect and ->get_modes callbacks, but things
became a bit fuzzy after trying to piece together the umpteenth
implemenation. Afaict most drivers just have bog-standard output
register
The pagelip ioctl itself is rather simply, so the hard work for this
patch is auditing all the drivers:
- exynos: Pageflip is protect with dev->struct_mutex and ...
synchronous. But nothing fancy going on, besides a check whether the
crtc is enabled, which should probably be somewhere in the d
Now that all framebuffer usage is properly refcounted, we are no
longer required to hold the modeset locks while dropping the last
reference. Hence implemented a fastpath which avoids the potential
stalls associated with grabbing mode_config.lock for the case where
there's no other reference around
Afact vmwgfx already has all the right refcounting implemented on the
backing storage, and we only need to ensure that the drm fb doesn't
disappear untimely. So holding onto the fb reference from _lookup
until vmw_kms_present has completed should be enough.
Signed-off-by: Daniel Vetter
---
drive
Useful for checking whether the new refcounting works as advertised.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
in
With the prep patch to encapsulate ->set_crtc calls, this is now
rather easy. Hooray for inconsistent semantics between ->set_crtc and
->page_flip, where the driver callback is supposed to update the fb
pointer, and ->update_plane, where the drm core does the same.
Also, since the drm core functio
Now plane->fb holds a reference onto it's framebuffer. Nothing too
fancy going on here:
- Extract __drm_framebuffer_unreference to be called when we know
we're not dropping the last reference, e.g. useful in the fb cleanup
code.
- Reduce the locked sections in the set_plane ioctl to only protec
We only need to ensure that the fb stays around for long enough. While
at it, only grab the modeset locks when we need them (since most
drivers don't implement the dirty callback, this should help jitter
and stalls when using the generic modeset driver).
Signed-off-by: Daniel Vetter
---
drivers/
We only need to push the fb unreference a bit down. While at it,
properly pass the return value from ->create_handle back to userspace.
Most drivers either return -ENODEV if they don't have a concept of
buffer objects (ast, cirrus, ...) or just install a handle for the
underlying gem object (which
And drop it where it's not needed. Most driver just lookup the gem
object, allocate an fb struct, fill in all the useful fields and then
register it with drm_framebuffer_init.
All of these operations are already separately locked, and since we
only put the fb into the fpriv->fbs list _after_ havin
Atm we still need to unconditionally take the modeset locks in the
rmfb paths. But eventually we only want to take them if there are
other users around as a slow-path. This way sane userspace avoids
blocking on edid reads and other stuff in rmfb if it ensures that the
fb isn't used anywhere by a cr
Since otherwise looking and reference-counting around
drm_framebuffer_lookup will be an unmanageable mess. With this change,
an object can either be found in the idr and will stay around once we
incremented the reference counter. Or it will be gone for good and
can't be looked up using its id any m
We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
framebuffers will be reaped when their assoiciated fb is closed.
Now these two cas
And replace all fb lookups with it. Also add a WARN to
drm_mode_object_find since that is now no longer the blessed interface
to look up an fb. And add kerneldoc to both functions.
This only updates all callsites, but immediately drops the acquired
refence again. Hence all callers still rely on th
Well, at least step 1. The goal here is that framebuffer objects can
survive outside of the mode_config lock, with just a reference held
as protection. The first step to get there is to introduce a special
fb_lock which protects fb lookup, creation and destruction, to make
them appear atomic.
This
->cursor_move uses mostly the same facilities in drivers as
->cursor_set, so pretty much nothing to fix up:
- ast/gma500/i915: They all use per-crtc registers to update the
cursor position. ast again touches the global cursor cache, but
that's ok since there's only one crtc.
- nouveau: nv50+
First convert ->cursor_set to only take the crtc lock, since that
seems to be the function with the least amount of state - the core
ioctl function doesn't check anything which can change at runtime, so
we don't have any object lifetime issues to contend.
The only thing which is important is that
*drumroll*
The basic idea is to protect per-crtc state which can change without
touching the output configuration with separate mutexes, i.e. all the
input side state to a crtc like framebuffers, cursor settings or plane
configuration. Holding such a crtc lock gives a read-lock on all the
other c
Ok, this one here is a bit more complicated, but for an RFC I've
figured I can be a bit sloppy. So just convert ever mutex_lock call,
including the interruptible one. Since other places (e.g. in the
execbuf ioctl) take the mode_config.mutex without bothering with
interruptible handling, I've figure
Only a resume method to account for.
v2: Fixup compilation.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
i
Just a call to drm_helper_resume_force_mode, obviously wants full
locking for that.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 31123b
Only two places:
- suspend/resume
- Some really strange mode validation tool with too much funny-lucking
hand-rolled conversion code.
- The recently-added lastclose fbdev restore code.
Better safe than sorry, so convert both places to keep the locking
semantics as much as possible.
Signed-off-b
Two exceptions:
- debugfs files only read information which is not related to crtc, so
can stay on the modeset_config lock.
- Same holds for the edp vdd work in intel_dp.c. Add a corresponding
WARN_ON and a comment next to the intel_dp struct fields for
documentation.
Signed-off-by: Daniel V
This is the first step towards introducing the new modeset locking
scheme. The plan is to put helper functions into place at all the
right places step-by-step, so that the final patch to switch on the
new locking scheme doesn't need to touch every single driver.
This helper here will serve as the
With refcounting we need to adjust framebuffer refcounts at each
callsite - much easier to do if they all call the same little helper
function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 19 +--
drivers/gpu/drm/drm_fb_helper.c|6 +++---
Some drivers don't have real ->create_handle callbacks.
- cirrus/ast/mga200: Returns either 0 or -EINVAL.
- udl: Didn't even bother with a callback, leading to a nice
userspace-triggerable OOPS.
- vmwgfx: This driver bothered with an implementation to return 0 as
the handle (which is the can
... by moving the bo_pin/bo_unpin manipulation of the pin_refcount
under the protection of the ttm reservation lock. pin/unpin seems
to get called from all over the place, so atm this is completely racy.
After this patch there are only a few places in cleanup functions
left which access ->pin_refc
With per-crtc locks modeset operations can run in parallel, and the
cursor code uses the device-global evo master channel for hw frobbing.
But the pageflip code can also sync with the master under some
circumstances. Hence just wrap things up in a mutex to ensure that
pushbuf access doesn't intermi
Doing this within the fb->destroy callback leads to a locking
nightmare. And all other drm drivers that restore the fbcon do
it in lastclose, too.
With this adjustments all fb->destroy callbacks optionally drop
references to any gem objects used as backing storage, call
drm_framebuffer_cleanup and
vmwgfx has an oddity, when failing to reference the surface it'll
return 0, since that's what the successfull drm_framebuffer_init will
leave behind in ret. Fix this up by returning -EINVAL.
Split out from all the other driver updates due to the above tiny
semantic change. Shouldn't matter though
With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by
And do a quick pass to adjust them to the last few (years?) of changes
...
This time actually compile-tested ;-)
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl |4 ++
drivers/gpu/drm/drm_crtc.c | 92 +++-
2 files changed, 48 inserti
- config_cleanup was confused: It claimed that callers need to hold
the modeset lock, but the connector|encoder_cleanup helpers grabbed
that themselves (note that crtc_cleanup did _not_ grab the modeset
lock). Which resulted in all drivers _not_ hodling the lock. Since
this is for single-th
Hi all,
Concurrent EDID reads and pageflips ftw!
Changes since the rfc:
- radeon/ttm/exynos prep patches/fixes merged.
- arm driver patches at least compile-tested.
- error handling fixed in a few cases, all spotted by Richard Wilbur,
- radeon/nouveau tested on one card each, didn't blow up right
On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
> I'm assuming you didn't also update your userspace gfx stack?
By that you mean x.org etc, right? Or GPU microcode too? In any case, I
haven't touched any of those deliberately, AFAICR at least.
> Does disabling the new DMA ring for t
On Thu, Jan 10, 2013 at 6:05 PM, Laurent Pinchart
wrote:
> On Thursday 10 January 2013 10:16:10 Dave Airlie wrote:
>> On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote:
>> > Updated version of DRM driver for TI LCD Controller. Since the initial
>> > version of the patch, which only supported TFP41
This patch considers DMA_NONE flag for other drivers not using
dma mapping framework with iommu such as 3d gpu driver or others.
For example, there might be 3d gpu driver that has its own iommu
hw unit and iommu table mapping mechanism. So in this case,
the dmabuf buffer imported into this driver
This patch releases sgt's sg object allocated by sgt_alloc_table
correctly.
When exynos_gem_map_dma_buf was called by dma_buf_map_attachmemt(),
the sgt's sg object was allocated by sg_alloc_tale() so
if dma_map_sg() is failed, the sg object should be released.
Signed-off-by: Inki Dae
Signed-off-
Hi Dave,
We're already at -rc3, so imo time to annoy you with a -next pull request.
Highlights:
- seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris
Wilson
- some leftover kill-agp on gen6+ patches from Ben
- hotplug improvements from Damien
- clear fb when allocated from sto
From: Seung-Woo Kim
If edid of vidi from user is invalid, size calculated from a number
of cea extensions can be wrong. So, validation should be checked.
Changelog v2:
- just code cleanup
. declare raw_edid only if vidi->connection is enabled.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyun
If edid of vidi from user is invalid, size calculated from a number
of cea extensions can be wrong. So, validation should be checked.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin.park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +++---
1 files changed, 3 insertions(+), 3 deletio
On Thu, Jan 10, 2013 at 6:05 PM, Laurent Pinchart
wrote:
> On Thursday 10 January 2013 10:16:10 Dave Airlie wrote:
>> On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote:
>> > Updated version of DRM driver for TI LCD Controller. Since the initial
>> > version of the patch, which only supported TFP41
https://bugs.freedesktop.org/show_bug.cgi?id=27704
--- Comment #4 from smoki ---
Created attachment 72833
--> https://bugs.freedesktop.org/attachment.cgi?id=72833&action=edit
fbo_firecube on rv280
--
You are receiving this mail because:
You are the assignee for the bug.
__
Hello Dave,
On 10/01/13 02:57, Dave Airlie wrote:
>> /**
>> - * Called via drm_exit() at module unload time or when pci device is
>> + * Called via drm_platform_exit() at module unload time or when pci device
>> is
>>* unplugged.
>
> Not really correct, its called from drm_pci_exit, drm_usb
https://bugs.freedesktop.org/show_bug.cgi?id=27704
--- Comment #3 from smoki ---
Created attachment 72832
--> https://bugs.freedesktop.org/attachment.cgi?id=72832&action=edit
fgl_glxgears -fbo on rv280
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=27704
--- Comment #2 from smoki ---
It fails in formats chooser, but it works for every format in firecube
just fine here on rv280 if i leave in radeon_texture.c just one format in that
function:
static gl_format radeonChooseTexFormat(rade
Hi Dave,
Pretty much all just major fixes:
- 2 pieces of duct-tape for the ilk bug.
- Sprite regression fixes from Chris.
- OOPS fix for a div-by-zero from Chris, regression due to the modeset
rework in 3.7, now brought to light by a benign change in 3.8.
- Fix interrupted bo pinning, used to wo
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/2a897145/attachment.html>
From: Alex Deucher
Hi Dave,
Fixes for UMS mode which has been broken for a while plus an rn50 fix
and a dma fix.
The following changes since commit 82ba789f48de669fd0bbc84c326f07571d078572:
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel (2013-01-11 07:52
https://bugs.freedesktop.org/show_bug.cgi?id=58354
--- Comment #20 from Alexandre Demers ---
Created attachment 72822
--> https://bugs.freedesktop.org/attachment.cgi?id=72822&action=edit
errors.log when tropics froze with patch 72794
It was originally about 53MB since it kept pumping messages
https://bugs.freedesktop.org/show_bug.cgi?id=58354
--- Comment #19 from Alexandre Demers ---
(In reply to comment #18)
> Created attachment 72794 [details] [review]
> possible fix
>
> Does this kernel patch help?
No. I was able to catch something in errors.log and kernel.log though. I'm
attachi
2013/1/10 Laurent Pinchart :
> Hi Vikas,
>
> Thank you for the patch.
>
> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>> On 3 January 2013 16:29, Tomasz Figa wrote:
>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>> >> From: Vikas Sajjan
>> >>
>> >> Signed-off-by: V
On Thursday 10 January 2013 10:16:10 Dave Airlie wrote:
> On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote:
> > Updated version of DRM driver for TI LCD Controller. Since the initial
> > version of the patch, which only supported TFP410 DVI output, I've added
> > an output driver for LCD panels (f
On Thu, Jan 10, 2013 at 3:32 PM, Borislav Petkov wrote:
> On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
>> I'm assuming you didn't also update your userspace gfx stack?
>
> By that you mean x.org etc, right? Or GPU microcode too? In any case, I
> haven't touched any of those delibe
Applied.
Thanks,
Inki Dae
2013/1/4 Rahul Sharma :
> There's no need to allocate edid twice and do a memcpy when drm helpers
> exist to do just that. This patch cleans that interaction up, and
> doesn't keep the edid hanging around in the connector.
>
> v4:
> - removed error check for drm_mode_con
https://bugzilla.kernel.org/show_bug.cgi?id=52491
--- Comment #2 from Bruno J. 2013-01-10 23:00:51 ---
Still happening in rc3
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the
https://bugs.freedesktop.org/show_bug.cgi?id=59219
ebigge...@gmail.com changed:
What|Removed |Added
Attachment #72816|text/plain |application/x-gzip
mime ty
https://bugs.freedesktop.org/show_bug.cgi?id=59219
Priority: medium
Bug ID: 59219
Assignee: dri-devel@lists.freedesktop.org
Summary: [radeon BUG] Sleeping function called from invalid
context
Severity: minor
Classificatio
From: Alex Deucher
Hi Dave,
Fixes for UMS mode which has been broken for a while plus an rn50 fix
and a dma fix.
The following changes since commit 82ba789f48de669fd0bbc84c326f07571d078572:
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel (2013-01-11 07:52
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130110/0b0008cf/attachment.html>
On Thu, 10 Jan 2013 21:47:53 +0100
Daniel Vetter wrote:
> Only two places:
> - suspend/resume
> - Some really strange mode validation tool with too much funny-lucking
> hand-rolled conversion code.
> - The recently-added lastclose fbdev restore code.
>
> Better safe than sorry, so convert both
Hi Linus,
Just intel fixes, including getting the Ironlake systems back to the state
they were in for 3.6.
Dave.
The following changes since commit ecf02a607bd801e742d7bb35c6e40f7ca15edf03:
Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86
(2013-01-10 09:09:41 -0800
On Thu, 10 Jan 2013 22:00:20 +0100
David Herrmann wrote:
> Hi Jesse
>
> On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes
> wrote:
> > On Fri, 28 Sep 2012 23:44:18 +0200
> > David Herrmann wrote:
> >
> >> Hi
> >>
> >> This is revision 2 of the manpages for libdrm. I converted everything to
> >>
On Thu, 10 Jan 2013, Inki Dae wrote:
> 2013/1/10 Laurent Pinchart :
>> Hi Vikas,
>>
>> Thank you for the patch.
>>
>> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>>> On 3 January 2013 16:29, Tomasz Figa wrote:
>>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>>> >>
Hi Jesse
On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes wrote:
> On Fri, 28 Sep 2012 23:44:18 +0200
> David Herrmann wrote:
>
>> Hi
>>
>> This is revision 2 of the manpages for libdrm. I converted everything to
>> docbook
>> XML. This makes it easier to write them (troff is really hard to read)
On Thu, Jan 10, 2013 at 9:48 PM, Daniel Vetter wrote:
> Otherwise it seems like we can get stuck with concurrent waiters.
> Right now this /shouldn't/ be a problem, since all pending pageflip
> waiters are serialized by the one mode_config.mutex, so there's at
> most on waiter. But better paranoid
Otherwise it seems like we can get stuck with concurrent waiters.
Right now this /shouldn't/ be a problem, since all pending pageflip
waiters are serialized by the one mode_config.mutex, so there's at
most on waiter. But better paranoid than sorry, since this is tricky
code.
v2: WARN_ON(waitqueue_
We need to make sure that the fbcon is still bound when touching the
hw, since otherwise we might corrupt the modeset state of kms clients.
X mostly works around that with VT switching and setting the VT into
raw mode, which disables most fbcon events.
Raw kms test programs though don't do that da
Now that framebuffer are reference-counted for all use-sites, update
the documentation accordingly to stress the new rules for
initialization and teardown.
Also add a short paragraph about the implications for drivers of the
new locking rules.
Signed-off-by: Daniel Vetter
---
Documentation/DocB
The coup de grace of the entire journey. No more dropped frames every
10s on my testbox!
I've tried to audit all ->detect and ->get_modes callbacks, but things
became a bit fuzzy after trying to piece together the umpteenth
implemenation. Afaict most drivers just have bog-standard output
register
The pagelip ioctl itself is rather simply, so the hard work for this
patch is auditing all the drivers:
- exynos: Pageflip is protect with dev->struct_mutex and ...
synchronous. But nothing fancy going on, besides a check whether the
crtc is enabled, which should probably be somewhere in the d
Now that all framebuffer usage is properly refcounted, we are no
longer required to hold the modeset locks while dropping the last
reference. Hence implemented a fastpath which avoids the potential
stalls associated with grabbing mode_config.lock for the case where
there's no other reference around
On Thu, 10 Jan 2013 22:00:20 +0100
David Herrmann wrote:
> Hi Jesse
>
> On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes
> wrote:
> > On Fri, 28 Sep 2012 23:44:18 +0200
> > David Herrmann wrote:
> >
> >> Hi
> >>
> >> This is revision 2 of the manpages for libdrm. I converted everything to
> >>
Afact vmwgfx already has all the right refcounting implemented on the
backing storage, and we only need to ensure that the drm fb doesn't
disappear untimely. So holding onto the fb reference from _lookup
until vmw_kms_present has completed should be enough.
Signed-off-by: Daniel Vetter
---
drive
Useful for checking whether the new refcounting works as advertised.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
in
With the prep patch to encapsulate ->set_crtc calls, this is now
rather easy. Hooray for inconsistent semantics between ->set_crtc and
->page_flip, where the driver callback is supposed to update the fb
pointer, and ->update_plane, where the drm core does the same.
Also, since the drm core functio
Now plane->fb holds a reference onto it's framebuffer. Nothing too
fancy going on here:
- Extract __drm_framebuffer_unreference to be called when we know
we're not dropping the last reference, e.g. useful in the fb cleanup
code.
- Reduce the locked sections in the set_plane ioctl to only protec
We only need to ensure that the fb stays around for long enough. While
at it, only grab the modeset locks when we need them (since most
drivers don't implement the dirty callback, this should help jitter
and stalls when using the generic modeset driver).
Signed-off-by: Daniel Vetter
---
drivers/
We only need to push the fb unreference a bit down. While at it,
properly pass the return value from ->create_handle back to userspace.
Most drivers either return -ENODEV if they don't have a concept of
buffer objects (ast, cirrus, ...) or just install a handle for the
underlying gem object (which
And drop it where it's not needed. Most driver just lookup the gem
object, allocate an fb struct, fill in all the useful fields and then
register it with drm_framebuffer_init.
All of these operations are already separately locked, and since we
only put the fb into the fpriv->fbs list _after_ havin
Atm we still need to unconditionally take the modeset locks in the
rmfb paths. But eventually we only want to take them if there are
other users around as a slow-path. This way sane userspace avoids
blocking on edid reads and other stuff in rmfb if it ensures that the
fb isn't used anywhere by a cr
Since otherwise looking and reference-counting around
drm_framebuffer_lookup will be an unmanageable mess. With this change,
an object can either be found in the idr and will stay around once we
incremented the reference counter. Or it will be gone for good and
can't be looked up using its id any m
We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
framebuffers will be reaped when their assoiciated fb is closed.
Now these two cas
Well, at least step 1. The goal here is that framebuffer objects can
survive outside of the mode_config lock, with just a reference held
as protection. The first step to get there is to introduce a special
fb_lock which protects fb lookup, creation and destruction, to make
them appear atomic.
This
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/3452a451/attachment.html>
And replace all fb lookups with it. Also add a WARN to
drm_mode_object_find since that is now no longer the blessed interface
to look up an fb. And add kerneldoc to both functions.
This only updates all callsites, but immediately drops the acquired
refence again. Hence all callers still rely on th
->cursor_move uses mostly the same facilities in drivers as
->cursor_set, so pretty much nothing to fix up:
- ast/gma500/i915: They all use per-crtc registers to update the
cursor position. ast again touches the global cursor cache, but
that's ok since there's only one crtc.
- nouveau: nv50+
First convert ->cursor_set to only take the crtc lock, since that
seems to be the function with the least amount of state - the core
ioctl function doesn't check anything which can change at runtime, so
we don't have any object lifetime issues to contend.
The only thing which is important is that
Ok, this one here is a bit more complicated, but for an RFC I've
figured I can be a bit sloppy. So just convert ever mutex_lock call,
including the interruptible one. Since other places (e.g. in the
execbuf ioctl) take the mode_config.mutex without bothering with
interruptible handling, I've figure
*drumroll*
The basic idea is to protect per-crtc state which can change without
touching the output configuration with separate mutexes, i.e. all the
input side state to a crtc like framebuffers, cursor settings or plane
configuration. Holding such a crtc lock gives a read-lock on all the
other c
1 - 100 of 138 matches
Mail list logo
