--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/d14a7f08/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140524/8f22eaa4/attachment.html>
reedesktop.org/archives/dri-devel/attachments/20140524/d89429d8/attachment.html>
iving 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/20140524/4e16778a/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/66e2b4bf/attachment.html>
without
experimental code from that bug.
--
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/20140524/a83dee4a/attachment-0001.html>
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/20140524/9e389dfd/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/b060edf7/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/8f6ef951/attachment.html>
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/20140524/c3659f62/attachment.html>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/bb2f8097/attachment.html>
Hello.
I tried to test whether it is OK (from point of view of reentrant) to use
mutex_lock() or mutex_lock_killable() inside shrinker functions when shrinker
functions do memory allocation, for drivers/gpu/drm/ttm/ttm_page_alloc_dma.c is
doing memory allocation with mutex lock held inside ttm_dma
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #4 from Vitaliy Filippov ---
Do you need any other details about this bug? :)
--
You are receiving this mail because:
You are watching the assignee of the bug.
One more time, with feeling..
Previous revision of series:
http://lists.freedesktop.org/archives/dri-devel/2014-March/055806.html
And if you prefer, in git form:
http://cgit.freedesktop.org/~robclark/linux/log/?h=cold-fusion
git://people.freedesktop.org/~robclark/linux cold-fusion
This series do
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a8b78e7..54e8fdb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm
The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically. This will be the basis of atomic-
modeset and nuclear-pageflip.
The basic flow is:
state = dev->atomic_begin();
for (... one or more ...)
obj->set_property(obj, state, prop, value);
For atomic, it will be quite convenient to not have to care so much
about locking order. And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.
Because we will want to eventually make locking even more fine grained
(giving locks to
An object property is an id (idr) for a drm mode object. This
will allow a property to be used set/get a framebuffer, CRTC, etc.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 60 +++--
include/drm/drm_crtc.h | 27
in
Like range, but values are signed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 45 +
include/drm/drm_crtc.h | 12
include/uapi/drm/drm_mode.h | 1 +
3 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/driv
Add a few more useful helpers to find mode objects.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 97 ++
include/drm/drm_crtc.h | 33
2 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/drm_
Split property values out into a different struct, so we can later
move property values into state structs. This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
And since we are touching all the same code, add support for mut
From: Ville Syrj?l?
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrj?l?
Signed-off-by: Rob Clark
--
From: Ville Syrj?l?
Refactor the code to check whether an object has a specific property
to a new function.
v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT
Signed-off-by: Ville Syrj?l?
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 25 ++---
1
We do actually want to permit FB's in atomic case, since FB will be
looked up like any other object property value in a few code paths
(like property value validation).
So split out into an internal function without the WARN_ON() which
we can use in those special cases.
Signed-off-by: Rob Clark
Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes. This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in t
Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes. This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in thei
All the call-sites save one need locking. By pushing it down and adding
a lockless flag, we can use the new spiffy atomic ww_mutex crtc locking
and simplify all the call-sites.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/armada/armada_fbdev.c | 4 +---
drivers/gpu/drm/drm_fb_cma_helper.c
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 57 ++--
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 6 ++
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 5 --
I find myself making this change locally whenever debugging FB reference
counting. Which seems a bit silly.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
i
TODO possibly just squash this back into "convert crtc/plane to
atomic"..
This reintroduces drm_modeset_lock_all() in a places that had not been
converted to more fine grained locking (setcrtc, setplane, etc). This
makes the locking equivalent to before.
Note that since mode_config.mutex is a dr
From: Sean Paul
BUG=chromium:336809
TEST=Tested on snow & peppy
Change-Id: Icd864ac52da9c973202f3ac4629824ef5eec2ac9
Signed-off-by: Sean Paul
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic.c | 4
drivers/gpu/drm/drm_crtc.c | 12 +---
include/drm/drm_crtc.h | 1
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/dae31012/attachment.html>
vel/attachments/20140524/52610a7d/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/beba17c7/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140524/0495a169/attachment.html>
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/8390cd88/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140524/0ab309f3/attachment.html>
h VIA chipset) in my AMD AthlonXP machine died
earlier this year.
--
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/20140524/
dri-devel/attachments/20140524/9ffa8502/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76861
Bug ID: 76861
Summary: radeon: flickering horizontal stripes/lines
Product: Drivers
Version: 2.5
Kernel Version: 3.15-rc6
Hardware: i386
OS: Linux
Tree: Mainli
The dma_buf_export function was updated in commit 4bcec44ffaf9 'dma-buf: use
reservation objects' to take a reservation object parameter; update Armada
export method accordingly.
This fixes the following compilation error:
drivers/gpu/drm/armada/armada_gem.c: In function ?armada_gem_prime_expor
41 matches
Mail list logo
