I'd still rather see some form of explicit cache flusing api, but I
can do that through my exporter (and probably will to get started).
Otherwise this looks good to me except for comment inline.
On Wed, Apr 18, 2012 at 6:52 AM, Daniel Vetter wrote:
> Compared to Rob Clark's RFC I've ditched the p
On Mon, Apr 23, 2012 at 09:18:25AM +0100, Chris Wilson wrote:
> 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 intro
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 ++
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 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.
Sig
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 --
incl
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
u
https://bugzilla.kernel.org/show_bug.cgi?id=43138
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #7 from bugtraq at 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
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:
t
https://bugs.freedesktop.org/show_bug.cgi?id=49083
Patrick Oberdorf changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://b
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
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 inserti
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
---
drivers/gpu/drm
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 changed
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):
drm/e
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 th
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 in
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 ++
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 int
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
b/driver
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 deleti
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
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):
drm/ex
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;
> >
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 Slusarz
> > ---
> > drivers/gpu/drm/nouveau/nv50_graph.c |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm
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 a
Le 23/04/2012 00:18, Marcin Slusarz a ?crit :
> 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 6899
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.
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; /* 50m
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Alex Deucher changed:
What|Removed |Added
Attachment #60473|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Alex Deucher changed:
What|Removed |Added
Attachment #60472|text/x-log |text/plain
mime type|
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 don
https://bugs.freedesktop.org/show_bug.cgi?id=49083
Alex Deucher changed:
What|Removed |Added
Component|Drivers/DRI/Radeon |Drivers/Gallium/r600
--
Configure bugmai
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
https://bugs.freedesktop.org/show_bug.cgi?id=39782
--- Comment #13 from Tom Stellard 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 message with this patch?
On Mon, Apr 23, 2012 at 8:26 AM, Treeve Jelbert 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
I'd still rather see some form of explicit cache flusing api, but I
can do that through my exporter (and probably will to get started).
Otherwise this looks good to me except for comment inline.
On Wed, Apr 18, 2012 at 6:52 AM, Daniel Vetter
wrote:
> Compared to Rob Clark's RFC I've ditched the
https://bugzilla.kernel.org/show_bug.cgi?id=43138
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
--- Comment #8
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 be
https://bugs.freedesktop.org/show_bug.cgi?id=49083
Patrick Oberdorf changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://b
> 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 th
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 usersp
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. T
> 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 doe
On Mon, Apr 23, 2012 at 09:18:25AM +0100, Chris Wilson wrote:
> 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 intro
On Mon, Apr 23, 2012 at 8:26 AM, Treeve Jelbert 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 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 cont
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 usersp
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Alex Deucher changed:
What|Removed |Added
Attachment #60473|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=48772
Alex Deucher changed:
What|Removed |Added
Attachment #60472|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=49083
Alex Deucher changed:
What|Removed |Added
Component|Drivers/DRI/Radeon |Drivers/Gallium/r600
--
Configure bugmai
wed-by: Adam Jackson
- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120423/7b8c12ed/attachment.pgp>
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
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 evictio
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 in
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)
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 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;
> >
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 Slusarz
> > ---
> > drivers/gpu/drm/nouveau/nv50_graph.c |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm
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 a
Le 23/04/2012 00:18, Marcin Slusarz a écrit :
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
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 ha
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
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.
>
>
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
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
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 comp
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 don
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 tr
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=49030
Michel D?nzer changed:
What|Removed |Added
Product|Mesa|DRI
Version|git
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
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
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 CE
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
Reviewed-by: Adam Jackson
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?
--
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: https://bugs.freedesktop.org/userprefs.cgi?tab
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 ++
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 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.
Sig
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 --
incl
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
u
> 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 th
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 kn
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. T
> 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 doe
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 inserti
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
---
drivers/gpu/drm
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 changed
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):
drm/e
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 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
Cc:
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 int
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
b/driver
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 deleti
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
1 - 100 of 124 matches
Mail list logo
