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/20131020/21fb5614/attachment.html>
sc80i00"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Primary display adapter: #9
With Regards
Grethus Bode
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/7521ac92/attachment.html>
On 10/17/2013 02:32 PM, Tomi Valkeinen wrote:
> On 17/10/13 15:17, Laurent Pinchart wrote:
>> On Thursday 17 October 2013 14:59:41 Tomi Valkeinen wrote:
>>> On 17/10/13 14:51, Laurent Pinchart wrote:
> I'm not sure if there's a specific need for the port or endpoint nodes
> in cases like th
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/574fceb7/attachment.html>
ffad7e93f44]
Looks like this isn't #66359, since glx gets loaded after glamoregl (this
wasn't the case with xorg-xserver 1.7 in xubuntu 13.04, but the crash was
exactly the same)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next
sure if it's a
correct solution.
--
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/20131020/91253b4b/attachment-0001.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/20131020/29e64f00/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/c1fc4bd5/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/b10d7401/attachment.html>
Instead of freeing minors in drm_dev_unregister(), we only unplug them and
delay the free to drm_dev_free(). Note that if drm_dev_register() has
never been called, minors are NULL and this has no effect.
This change is needed to allow early device unregistration. If we want to
call drm_dev_unregis
Don't delay minor removal to drm_put_minor(). Otherwise, user-space can
still open the minor and cause the kernel to oops. Instead, remove the
minor during unplug so any new open() will fail to access this minor.
Note that open() and drm_unplug_minor() are both protected by the global
DRM mutex so
There is no reason to delay debugfs-cleanup to drm_put_minor(). We should
forbid any access to debugfs files once the device is dead. Chances they
oops once a card was unplugged are very high, anyway.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 8
1 file changed, 4 in
drm_get_minor() is only used in one file. Make it static and add a
kernel-doc comment which documents the current semantics.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 19 +++
include/drm/drmP.h | 1 -
2 files changed, 11 insertions(+), 9 deletions(-)
Allow passing NULL as minor to simplify DRM destruction paths. Also remove
the double-pointer reset as it is no longer needed. drm_put_minor() is
only called when the underlying object is destroyed. Hence, resetting
minors to NULL is not necessary.
As drm_put_minor() is no longer used by other DRM
This protects drm_unplug_minor() against repeated calls so we can use it
in drm_put_minor(). This allows us to further simplify it in follow-ups as
we no longer do minor-destruction in both functions but only in
drm_unplug_minor().
Also add kernel-doc comments about what these calls do.
Signed-off
ue tracker:
https://github.com/ValveSoftware/steam-for-linux/issues/2732
--
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/20131020/42835569/attachment.html>
While working on a dpm bug
(https://bugs.freedesktop.org/show_bug.cgi?id=69723), I stumbled on a couple of
lines where we were reading and setting back the same values for no obvious
reason.
---
drivers/gpu/drm/radeon/ni_dpm.c | 17 -
1 file changed, 4 insertions(+), 13 deletio
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/af327bc3/attachment.html>
Subsequent threads returning EBUSY from vm_insert_pfn() was not
handled correctly. As a result concurrent access from new threads
to mmapped data caused SIGBUS.
See e79e0fe3
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drive
Re-arrange things a bit so that we can get work requested after a bo
fence passes, like pageflip, done before retiring bo's. Without any
sort of bo cache in userspace, some games can trigger hundred's of
transient bo's, which can cause retire to take a long time (5-10ms).
Obviously we want a bo ca
Enable using VG1 and VG2 for planes. Currently YUV/CSC or scaling is
not enabled, but ARGB and xRGB blending is.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 136 -
drivers/gpu/drm/msm/mdp4/mdp4_format.c | 16
drivers/gpu/drm/msm/md
resync to latest envytools db, fixes a typo: s/mpd4/mdp4/
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx.xml.h | 42 -
drivers/gpu/drm/msm/adreno/a3xx.xml.h | 46 ++---
drivers/gpu/drm/msm/adreno/adreno_common.xml.h | 10 +-
drivers/gpu/drm/msm/adre
Enable support for drm render nodes for msm by flagging the ioctls
that are safe and only needed for rendering.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/g
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/msm_drv.c | 15 -
drivers/gpu/drm/msm/msm_drv.h | 13 +++-
drivers/gpu/drm/msm/msm_gem.c | 120 +---
drivers/gpu/drm/msm/msm_gem_prime.c | 56
Fyi, here are the queued up patches I have so far for 3.13.
Rob Clark (6):
drm/msm: prime support
drm/msm: support render nodes
drm/msm: resync generated headers
drm/msm: add plane support
drm/msm: rework inactive-work
drm/msm: EBUSY status handling in msm_gem_fault()
drivers/gpu/drm
Subsequent threads returning EBUSY from vm_insert_pfn() was not
handled correctly. As a result concurrent access from new threads
to mmapped data caused SIGBUS.
See e79e0fe3
Signed-off-by: Rob Clark
---
drivers/gpu/drm/omapdrm/omap_gem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #13 from Kertesz Laszlo ---
I reverted commit 4076a65544e2de310cbf4eaadb13ee15bbfaaf4f, but still crashes
with dpm.
Reverting this commit changed back the CPU voltage handling as it was before.
It seems that the CPU power management
rubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/42f3990a/attachment.pgp>
riminal, 1883-1946
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131020/0c6155ec/attachment.pgp>
29 matches
Mail list logo
