On Sam, 2012-04-21 at 11:42 +0200, Christian König wrote:
Regarding the debugging of lockups I had the following on my in mind
todo list:
1. Rework the chip specific lockup detection code a bit more and
probably clean it up a bit.
2. Make the timeout a module parameter, cause compute
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #13 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-23
00:49:03 PDT ---
Created attachment 60472
-- https://bugs.freedesktop.org/attachment.cgi?id=60472
Xorg log running 2560x1440
--
Configure bugmail:
On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote:
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming gpu reset code needs exclusive access to the device.
This commit adds drm_driver flag which turns on read lock ioctl encapsulation.
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #14 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-04-23
00:52:30 PDT ---
Created attachment 60473
-- https://bugs.freedesktop.org/attachment.cgi?id=60473
DRM related kernel messages
Is this what you had in mind or would you
On 32-bit systems, a large args-buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 (drm/i915:
First try a normal large kmalloc for the temporary exec buffers).
Signed-off-by: Xi Wang
On 32-bit systems, a large args-num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed (drm/i915: Avoid
allocation for execbuffer object list).
Signed-off-by: Xi Wang xi.w...@gmail.com
Cc:
On Mon, 23 Apr 2012 04:06:41 -0400, Xi Wang xi.w...@gmail.com wrote:
On 32-bit systems, a large args-buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 (drm/i915:
First try a normal
On Mon, 23 Apr 2012 04:06:42 -0400, Xi Wang xi.w...@gmail.com wrote:
On 32-bit systems, a large args-num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed (drm/i915: Avoid
allocation for
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
-
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-04-23 09:16:31 ---
(In reply to comment #2)
-rw-r--r-- 1 root root 5504 Jan 19 04:25 CEDAR_me.bin
-rw-r--r-- 1 root root 4480 Jan 19 04:25 CEDAR_pfp.bin
-rw-r--r-- 1 root root 3072
https://bugs.freedesktop.org/show_bug.cgi?id=49030
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Product|Mesa|DRI
https://bugs.freedesktop.org/show_bug.cgi?id=49029
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Attachment #60410|text/x-log |text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=49029
--- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-04-23 02:29:32 PDT
---
Apart from that it's working fine but the lack of power management reduce the
run from a battery from 4h to 1h30.
I doubt it's all due to just that, but FWIW one
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #12 from 414N grsf...@tiscali.it 2012-04-23 02:53:34 PDT ---
Created attachment 60474
-- https://bugs.freedesktop.org/attachment.cgi?id=60474
xvmc log obtained via RADEON_DEBUG=fp,vp on mesa-git @ 20120423
(In reply to comment #11
Hi Mauro,
On Friday, April 20, 2012 3:37 PM Mauro Carvalho Chehab wrote:
(snipped)
So my rough-idea was to remove USERPTR support from kernel
drivers (if possible of course) and to provide an emulation
layer in the userspace code like libv4l2.
Please note that it is only a rough idea.
On Mon, 2012-04-23 at 11:18 +0200, Treeve Jelbert wrote:
Linux-3.3.3
$ dmesg|grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to userspace modesetting.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
This patch supports the PM for hdmi and mixer. Turn off hdmi and mixer
when suspended, and when resume, will turn on them by hdmi hotplug
detection if hdmi is attached.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
This patchset is to support dpms and PM for hdmi of exynos drm. The
exynos hdmi has internal and externel interrupt handler for hotplug
detection. We can select whether use which interrupt handler by power
state of hdmi.
The base of this patchset is Linux 3.4-rc4.
Joonyoung Shim (5):
The exynos_drm_hdmi_pdata struct have owned unnessary members. Remove
them and add a function pointer to configure hdmi hotplug detection pin.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |
The exynos hdmi supports two hdmi interrupts - external and internal, so
use platform_get_irq_byname to distinguish their resources.
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 11
We can use irq thread instead of workqueue
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 40 -
1 files changed, 5 insertions(+), 35 deletions(-)
diff --git
The power and clocks turns on always in exynos hdmi and mixer driver,
but we should turn off the power and clocks of exynos hdmi and mixer
when the hdmi cable unplugged or when hdmi unused.
There are two interrupt to detect hotplug of hdmi cable - internal
interrupt and external interrupt. The
this patch set fixes gem allocation and mapping issue between user space and
physical memory region.
this patch set is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 273a50fbcd2d2c0652bbda58dd1985f932ce6d75
Inki Dae (3):
the gem was already allocated at gem allocation time but is allocated
at page fault handler so this patch fixes the problem that gem was
allocated one more time.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
this patch fixes the problem that the physical memory region to be mapped
to user space could be exceeded. if page fault address was placed at between
buffer start and end then memory region to be mapped would be exceeded.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park
with this patch, if the memory region is physically non-continuous
then VM_MIXEDMAP is set to vm-vm_flags otherwise VM_PFNMAP.
we had missed this flag setting.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs commonly
have low video RAM, it doesn't make sense to put the kms console in VRAM
always. This driver places the kms console into system RAM, and does
On Mon, Apr 23, 2012 at 1:44 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs
commonly
have low video RAM, it doesn't make sense to put the kms console in
ends up in the in-VRAM object. I'll have to add defio support to make this
work
properly now that I think about it a bit more, but defio isn't a major
amount of work.
Ok
fbdev objects once exposed to userspace or to fbcon, thanks to some wonderful
API design way back, the mmaps on the
this patch set adds the following features:
cache attribute support
- user can set cache attributes(such as cachable, non-cachable or writecombime)
to the buffer to be allocated by gem framework.
drm prime support
- this feature had recentrly been introduced to share a buffer between drivers
with this patch, user application can set cache attribute(such as
cachable, writecombime or non-cachable) of the memory region allocated
by gem framework.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
this patch adds exynos specific codes for DRM Prime feature.
with this patch, user application can get file descriptor
from gem handle through DRM_IOCTL_PRIME_HANDLE_TO_FD ioctl
command(export) and also gem handle from file descriptor
through DRM_IOCTL_PRIME_FD_TO_HANLDE(import) ioctl command.
this feature could be used to use memory region allocated by malloc() in user
mode and mmaped memory region allocated by other memory allocators. userptr
interface can identify memory type through vm_flags value and would get
pages or page frame numbers to user space appropriately.
Signed-off-by:
this patch adds a feature to get a gem buffer information and user application
can get the gem buffer information simply in runtime through gem handle.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c |
On Sun, 2012-04-22 at 11:40 -0500, Ian Pilcher wrote:
EDID vendor IDs are always 3 characters long (4 with the terminating
0). It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.
Signed-off-by: Ian Pilcher arequip...@gmail.com
Reviewed-by:
On Mon, Apr 23, 2012 at 10:43:08AM +0200, Martin Peres wrote:
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing
Hey,
Just a minor mistake spotted while skimming through the patch.
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
+static inline uint64_t nv_timeout(struct drm_device *dev)
+{
+ uint64_t tm = 20ULL;
+ if (nouveau_gpu_reset_in_progress(dev))
+ tm /= 40; /* 50ms
Le 23/04/2012 18:32, Marcin Slusarz a écrit :
Just run piglit. Even quick tests can cause ~5 lockups (it eventually messes
up DDX channel, but this patchset can't fix this case).
You can run fs-discard-exit-2 test first - for me it causes instant GPU lockup.
Marcin
Great, Thanks.
Did you
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
Signed-off-by: Marcin Slusarzmarcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote:
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming gpu reset code needs exclusive access to the device.
This commit adds
On Mon, Apr 23, 2012 at 07:09:57PM +0200, Martin Peres wrote:
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
Signed-off-by: Marcin Slusarzmarcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
On Mon, Apr 23, 2012 at 06:46:41PM +0200, Martin Peres wrote:
Hey,
Just a minor mistake spotted while skimming through the patch.
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
+static inline uint64_t nv_timeout(struct drm_device *dev)
+{
+ uint64_t tm = 20ULL;
+ if
https://bugs.freedesktop.org/show_bug.cgi?id=49083
Bug #: 49083
Summary: Crashing when open gnome-control-center 3.4.1
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
On Mon, Apr 23, 2012 at 07:20:35PM +0200, Marcin Slusarz wrote:
On Mon, Apr 23, 2012 at 09:51:48AM +0200, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote:
Nouveau, in normal circumstances, does not need device lock for every
ioctl,
but incoming gpu
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #60472|text/x-log |text/plain
mime
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Attachment #60473|text/x-log |text/plain
mime
On Monday 23 April 2012 12:18:55 Michel Dänzer wrote:
On Mon, 2012-04-23 at 11:18 +0200, Treeve Jelbert wrote:
Linux-3.3.3
$ dmesg|grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to userspace modesetting.
[drm] Supports vblank timestamp caching Rev 1
Em 23-04-2012 07:50, Marek Szyprowski escreveu:
Hi Mauro,
On Friday, April 20, 2012 3:37 PM Mauro Carvalho Chehab wrote:
(snipped)
So my rough-idea was to remove USERPTR support from kernel
drivers (if possible of course) and to provide an emulation
layer in the userspace code like
On Mon, Apr 23, 2012 at 8:26 AM, Treeve Jelbert tre...@scarlet.be wrote:
On Monday 23 April 2012 12:18:55 Michel Dänzer wrote:
On Mon, 2012-04-23 at 11:18 +0200, Treeve Jelbert wrote:
Linux-3.3.3
$ dmesg|grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to userspace
On Mon, Apr 23, 2012 at 09:18:25AM +0100, Chris Wilson wrote:
On Mon, 23 Apr 2012 04:06:41 -0400, Xi Wang xi.w...@gmail.com wrote:
On 32-bit systems, a large args-buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability
https://bugs.freedesktop.org/show_bug.cgi?id=49083
Patrick Oberdorf obi12...@googlemail.com changed:
What|Removed |Added
Priority|medium |high
--
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #7 from bugt...@hobbit.in-berlin.de 2012-04-23 22:25:51 ---
locate CEDAR_ shows only these 3 files, so there should be no other
duplicates with the same names on my filesystem...
as a stock Debian kernel/initrd is showing same
https://bugzilla.kernel.org/show_bug.cgi?id=43138
Jérôme Glisse gli...@freedesktop.org changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #13 from Tom Stellard tstel...@gmail.com 2012-04-23 17:56:54 PDT
---
Created attachment 60501
-- https://bugs.freedesktop.org/attachment.cgi?id=60501
Possible fix for too many indirections on r400
Do you still see the error
On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
Following up on the above, the commit which introduces the panics during
boot is this one:
commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse
On Mon, 2012-04-23 at 00:18 +0200, Marcin Slusarz wrote:
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Ah, thanks for tackling this issue. It's been long on my list of
this feature could be used to use memory region allocated by malloc() in user
mode and mmaped memory region allocated by other memory allocators. userptr
interface can identify memory type through vm_flags value and would get
pages or page frame numbers to user space appropriately.
changelog v2:
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming "gpu reset" code needs exclusive access to the device.
This commit adds drm_driver flag which turns on read lock ioctl encapsulation.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/drm_drv.c |6
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
---
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #11 from Tom Stellard 2012-04-22 18:10:00
PDT ---
(In reply to comment #10)
> Created attachment 57314 [details]
> xvmc log obtained via RADEON_DEBUG=all
>
> Having a similar problem on a R420.
> When using mplayer -vo xvmc to play
On Sun, 2012-04-22 at 08:26 +0100, Dave Airlie wrote:
> On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
> wrote:
> > David & co, any ideas?
>
> I've been asking Ben about this, I might have to use a bit more pressure,
I unfortunately haven't yet had any ideas which could be useful aside
from
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #45 from Alexandre Demers
2012-04-22 22:56:08 PDT ---
I'm now working with a 3.4-rc4 kernel. I activated ColorTiling2D. However, it
didn't change anything.
On the other hand, if you have the hardware under hand, I want to let you
On Sam, 2012-04-21 at 11:42 +0200, Christian K?nig wrote:
>
> Regarding the debugging of lockups I had the following on my "in mind
> todo" list:
> 1. Rework the chip specific lockup detection code a bit more and
> probably clean it up a bit.
> 2. Make the timeout a module parameter, cause
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #13 from Tvrtko Ursulin 2012-04-23
00:49:03 PDT ---
Created attachment 60472
--> https://bugs.freedesktop.org/attachment.cgi?id=60472
Xorg log running 2560x1440
--
Configure bugmail:
On Mon, Apr 23, 2012 at 12:18:28AM +0200, Marcin Slusarz wrote:
> Nouveau, in normal circumstances, does not need device lock for every ioctl,
> but incoming "gpu reset" code needs exclusive access to the device.
> This commit adds drm_driver flag which turns on read lock ioctl encapsulation.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=48772
--- Comment #14 from Tvrtko Ursulin 2012-04-23
00:52:30 PDT ---
Created attachment 60473
--> https://bugs.freedesktop.org/attachment.cgi?id=60473
DRM related kernel messages
Is this what you had in mind or would you like something more?
--
On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").
Signed-off-by: Xi Wang
On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.
This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").
Signed-off-by: Xi Wang
Cc: Chris Wilson
Cc:
On Mon, 23 Apr 2012 04:06:41 -0400, Xi Wang wrote:
> On 32-bit systems, a large args->buffer_count from userspace via ioctl
> may overflow the allocation size, leading to out-of-bounds access.
>
> This vulnerability was introduced in commit 8408c282 ("drm/i915:
> First try a normal large kmalloc
On Mon, 23 Apr 2012 04:06:42 -0400, Xi Wang wrote:
> On 32-bit systems, a large args->num_cliprects from userspace via ioctl
> may overflow the allocation size, leading to out-of-bounds access.
>
> This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
> allocation for execbuffer
Le 23/04/2012 00:18, Marcin Slusarz a ?crit :
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> - CPU-only bo
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #6 from Michel D?nzer 2012-04-23 09:16:31
---
(In reply to comment #2)
> -rw-r--r-- 1 root root 5504 Jan 19 04:25 CEDAR_me.bin
> -rw-r--r-- 1 root root 4480 Jan 19 04:25 CEDAR_pfp.bin
> -rw-r--r-- 1 root root 3072 Jan 19 04:25
https://bugs.freedesktop.org/show_bug.cgi?id=49030
Michel D?nzer changed:
What|Removed |Added
Product|Mesa|DRI
Version|git
https://bugs.freedesktop.org/show_bug.cgi?id=49029
Michel D?nzer changed:
What|Removed |Added
Attachment #60410|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=49029
--- Comment #1 from Michel D?nzer 2012-04-23 02:29:32
PDT ---
> Apart from that it's working fine but the lack of power management reduce the
> run from a battery from 4h to 1h30.
I doubt it's all due to just that, but FWIW one thing you can
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #12 from 414N 2012-04-23 02:53:34 PDT ---
Created attachment 60474
--> https://bugs.freedesktop.org/attachment.cgi?id=60474
xvmc log obtained via RADEON_DEBUG=fp,vp on mesa-git @ 20120423
(In reply to comment #11)
> Can y
Hi Mauro,
On Friday, April 20, 2012 3:37 PM Mauro Carvalho Chehab wrote:
(snipped)
> >> So my rough-idea was to remove USERPTR support from kernel
> >> drivers (if possible of course) and to provide an emulation
> >> layer in the userspace code like libv4l2.
> >>
> >> Please note that it is
i2c_nforce2 i2c_core forcedeth parport_pc
parport button evdev k8temp
-- next part --
A non-text attachment was scrubbed...
Name: config-3.3.3.zip
Type: application/zip
Size: 15331 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120
On Mon, 2012-04-23 at 11:18 +0200, Treeve Jelbert wrote:
> Linux-3.3.3
>
> $ dmesg|grep drm
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon defaulting to userspace modesetting.
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] No driver support for vblank timestamp
This patch supports the PM for hdmi and mixer. Turn off hdmi and mixer
when suspended, and when resume, will turn on them by hdmi hotplug
detection if hdmi is attached.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 32
This patchset is to support dpms and PM for hdmi of exynos drm. The
exynos hdmi has internal and externel interrupt handler for hotplug
detection. We can select whether use which interrupt handler by power
state of hdmi.
The base of this patchset is Linux 3.4-rc4.
Joonyoung Shim (5):
The exynos_drm_hdmi_pdata struct have owned unnessary members. Remove
them and add a function pointer to configure hdmi hotplug detection pin.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 ++---
include/drm/exynos_drm.h
The exynos hdmi supports two hdmi interrupts - external and internal, so
use platform_get_irq_byname to distinguish their resources.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +--
1 files changed, 5 insertions(+), 6
We can use irq thread instead of workqueue
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 40 -
1 files changed, 5 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
The power and clocks turns on always in exynos hdmi and mixer driver,
but we should turn off the power and clocks of exynos hdmi and mixer
when the hdmi cable unplugged or when hdmi unused.
There are two interrupt to detect hotplug of hdmi cable - internal
interrupt and external interrupt. The
this patch set fixes gem allocation and mapping issue between user space and
physical memory region.
this patch set is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 273a50fbcd2d2c0652bbda58dd1985f932ce6d75
Inki Dae (3):
the gem was already allocated at gem allocation time but is allocated
at page fault handler so this patch fixes the problem that gem was
allocated one more time.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
1 files
this patch fixes the problem that the physical memory region to be mapped
to user space could be exceeded. if page fault address was placed at between
buffer start and end then memory region to be mapped would be exceeded.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
with this patch, if the memory region is physically non-continuous
then VM_MIXEDMAP is set to vm->vm_flags otherwise VM_PFNMAP.
we had missed this flag setting.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |2 ++
1 files changed, 2
> This driver has a slightly different design than other KMS drivers, but
> future server chips will probably share similiar setup. As these GPUs commonly
> have low video RAM, it doesn't make sense to put the kms console in VRAM
> always. This driver places the kms console into system RAM, and
On Mon, Apr 23, 2012 at 1:44 PM, Alan Cox wrote:
>> This driver has a slightly different design than other KMS drivers, but
>> future server chips will probably share similiar setup. As these GPUs
>> commonly
>> have low video RAM, it doesn't make sense to put the kms console in VRAM
>> always.
> ends up in the in-VRAM object. I'll have to add defio support to make this
> work
> properly now that I think about it a bit more, but defio isn't a major
> amount of work.
Ok
> fbdev objects once exposed to userspace or to fbcon, thanks to some wonderful
> API design way back, the mmaps on
this patch set adds the following features:
cache attribute support
- user can set cache attributes(such as cachable, non-cachable or writecombime)
to the buffer to be allocated by gem framework.
drm prime support
- this feature had recentrly been introduced to share a buffer between drivers
with this patch, user application can set cache attribute(such as
cachable, writecombime or non-cachable) of the memory region allocated
by gem framework.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 49 --
this patch adds exynos specific codes for DRM Prime feature.
with this patch, user application can get file descriptor
from gem handle through DRM_IOCTL_PRIME_HANDLE_TO_FD ioctl
command(export) and also gem handle from file descriptor
through DRM_IOCTL_PRIME_FD_TO_HANLDE(import) ioctl command.
this feature could be used to use memory region allocated by malloc() in user
mode and mmaped memory region allocated by other memory allocators. userptr
interface can identify memory type through vm_flags value and would get
pages or page frame numbers to user space appropriately.
Signed-off-by:
this patch adds a feature to get a gem buffer information and user application
can get the gem buffer information simply in runtime through gem handle.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 26
1 - 100 of 122 matches
Mail list logo
