On 20/10/2012 11:26, Heinz Diehl wrote:
> On 20.10.2012, Linus Torvalds wrote:
>
>> Added more appropriate people to this. Added both i915 and nouveau
>> people, since apparently that fine piece of hardware has both.
>>
>> Guys, any ideas?
>
> Plese see https://lkml.org/lkml/2012/10/19/371 , this i
Hi,
Following to my shared talk with krh, danvet and Timothée Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for incl
On 13/12/2012 11:02, Ozan Çağlayan wrote:
Hi,
I have a geforce 9600gt (nv94) display adapter which has its fan
running at 100% speed. Yesterday I've compiled and booted with the
latest nouveau-2.6 tree. sensors from lm_sensors can correctly acquire
GPU temperature and PWM speed but as far as I u
From: Kristian Høgsberg
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
v2: fix a off-by-one overlap as suggested by ihad...@research.bell-labs.com
Signed-off-by: Martin Peres
---
drivers/gpu/drm
From: Kristian Høgsberg
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
2 f
From: Martin Peres
Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff
. Render nodes can be used without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.
v2: Martin Peres
- Allow render nodes to access DRM_UNLOCKED IOCTLs)
Signed-off-by: Kristian Høgsberg
Signed-off-by: Martin Peres
---
drivers/gpu/drm/drm_drv.c | 13
From: Martin Peres
Signed-off-by: Martin Peres
---
.gitignore | 1 +
tests/Makefile.am| 1 +
tests/same_device_but_type.c | 52
xf86drm.c| 44 +
xf86drm.h
From: Martin Peres
Signed-off-by: Martin Peres
---
nouveau/nouveau.c | 11 +--
nouveau/nouveau.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 940d933..1402852 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
From: Martin Peres
Signed-off-by: Martin Peres
---
tests/name_from_fd.c | 19 ++
xf86drm.c| 105 ---
xf86drm.h| 7
3 files changed, 100 insertions(+), 31 deletions(-)
diff --git a/tests/name_from_fd.c b
From: Martin Peres
Signed-off-by: Martin Peres
---
nouveau/libdrm_nouveau.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 6170613..f3b99cf 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau
From: Martin Peres
Signed-off-by: Martin Peres
---
configure.ac | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0c19929..df56066 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([libdrm
From: Martin Peres
Signed-off-by: Martin Peres
---
dri2proto.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/dri2proto.h b/dri2proto.h
index 128b807..4d11ba7 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -35,7 +35,7 @@
#define DRI2_NAME
From: Martin Peres
Signed-off-by: Martin Peres
---
glx/glxdri2.c | 3 ++-
hw/xfree86/dri2/dri2.c| 11 ++-
hw/xfree86/dri2/dri2.h| 8 ++--
hw/xfree86/dri2/dri2ext.c | 8 ++--
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/glx/glxdri2.c b
From: Martin Peres
Signed-off-by: Martin Peres
---
configure.ac | 2 +-
src/nouveau_dri2.c | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ff9c337..61dfb01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,7 +67,7
From: Martin Peres
Signed-off-by: Martin Peres
---
src/gallium/state_trackers/egl/x11/x11_screen.c | 2 +-
src/glx/dri2.c | 6 +-
src/glx/dri2.h | 3 ++-
src/glx/dri2_glx.c | 20
Hi Nouveau enthusiasts,
One week ago was merged the thermal/fan management code for most nvidia
cards.
So far, no major issue arose but we would like to have more testing as
soon as possible to deliver a nice and solid support when Linux 3.8 is
released.
Thermal management is split into tw
Hi,
Following to my shared talk with krh, danvet and Timothée Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for incl
!
Martin
Hey this is nice! I'll try it tonight when I'm back home.
Thanks :)
Here you go :)
I managed to reproduce the issue. Please test this patch!
Thanks for reporting,
Martin
>From 0227e8a93c697c325fb89b31b16aa5fe565c64d5 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Mon
Le 18/12/2012 13:03, Daniel Vetter a écrit :
On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote:
Hi,
Following to my shared talk with krh, danvet and Timothée Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in
the graphics stack.
Today, I
On 19/12/2012 20:39, Ozan Çağlayan wrote:
Here you go :)
I managed to reproduce the issue. Please test this patch!
Okay switching to automatic mode when pwm1 == 100 now gradually (in a
few seconds, it is not cut down to 35 suddenly) lowers it down to 35.
Switching to automatic mode while in man
Le 20/12/2012 14:07, Ozan Çağlayan a écrit :
So, we had some discussions within the nouveau community about
this and we decided that 0 would mean, no updates on the current status.
Anything against it?
So if I switch automatic mode on and then disable it then do some heavy GPU
processing, the f
On 21/12/2012 13:04, Ozan Çağlayan wrote:
Of course it is, but why would you disable automatic fan management?
You are supposed to activate it and let it activated at all time.
It's not me but someone inexperienced playing with sysfs tunables for example :)
Ah, sure. Well, there is documentat
Le 07/01/2013 17:25, Ozan Çağlayan a écrit :
We will be waiting a until one kernel is released before activating fan
management by default.
So these fan stuff will be merged into 3.9?
Yeah, quite likely :)
I see no reasons for us not to. So far, all bugs have been fixed.
_
y the attached patch please ?
Martin
>From ea15dc1cf87236da78e8e88ecc3864ffab006ae0 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Sat, 20 Oct 2012 00:08:15 +0200
Subject: [PATCH] drm/nouveau/bios: improve error handling when reading the
vbios from ACPI
Reported-by: Pawel Sikora
Signed-off-by
rom f09d58dc23a6e48ed56a1d9bf803f800f0c59e83 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Sat, 20 Oct 2012 11:03:36 +0200
Subject: [PATCH] drm/nouveau/bios: improve error handling when reading the
vbios from ACPI
Reported-by: Pawel Sikora
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/core/subdev/bios/bas
Le 04/01/2012 08:20, Dan Carpenter a écrit :
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index 0393721..3508de9 100644
--- a/drivers/gpu/drm/nouveau
Le 10/01/2012 06:39, Dan Carpenter a écrit :
On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote:
Le 04/01/2012 08:20, Dan Carpenter a écrit :
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm
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
- ignor
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 ha
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 04/06/2012 13:30, Christian König a écrit :
On 04.06.2012 10:44, Lauri Kasanen wrote:
So the issue is the location of the info, not the format. I'd be more
than happy to split it into six files (default_core_clock,
current_core_clock...) that each offer just a kHz number, just like
the cpuf
Le 04/06/2012 16:31, Jerome Glisse a écrit :
I don't think sysfs is the way to go, i am pretty sure that power
management will change drasticly again in the future especialy btw
discret and integrated GPU. I would rather have hardware specific
ioctl.
Cheers,
Jerome
Any particular idea of what
Le 04/06/2012 17:18, Jerome Glisse a écrit :
My experience is that things that are true today for GPU, are not
tomorrow. Yes there will still be clock/voltage, but there could be
new complete different things, like shutting down block.
IMO, this isn't something the user should ever be aware of.
Answers inlined.
Le 04/06/2012 19:19, Jerome Glisse a écrit :
My point is that there is no way for power management to find an API
that fits all GPU. If i were to do it now, i would have one ioctl
version for r3xx, one for r5xx, one for r6xx/r7xx, one for r8xx, one
for r9xx, ... yes there would
On 04.06.2012 20:29, Jerome Glisse wrote:
On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
Yeah, I get your point as a kernel dev, but I pitty the userspace dev that
will need to figure out how to use all these ioctls and configuration
options.
My point there is that we do the userspace b
On 04.06.2012 21:54, Daniel Vetter wrote:
In i915-land we're trying to make things Just Work. If needed we can
expose (generation/platform-specific) tunables in sysfs. But on snb and
later the combination of rc6+gpu turbo (mostly handled all by hw) is
rather ok, so I don't see anything going abo
On 31/01/2013 11:53, Laurent Pinchart wrote:
On Friday 11 January 2013 21:27:03 Laurent Pinchart wrote:
Hi everybody,
Would anyone be interested in meeting at the FOSDEM to discuss the Common
Display Framework ? There will be a CDF meeting at the ELC at the end of
February, the FOSDEM would be
Hi Konrad,
On 04/03/2013 19:40, Konrad Rzeszutek Wilk wrote:> After git merge
ab7826595e9ec51a51f622c5fc91e2f59440481a
> (Merge tag 'mfd-3.9-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6)
> the nouveau driver ends up shutting of the machine when booting.
>
>
> I hadn't done
p 17 00:00:00 2001
From: Martin Peres
Date: Tue, 5 Mar 2013 10:26:30 +0100
Subject: [PATCH 1/8] drm/nv40/therm: improve selection between the old and the
new style
The condition to select between the old and new style was a thinko
as rnndb orders chipsets based on their release date (or general
chron
On 11/03/2013 13:38, Konrad Rzeszutek Wilk wrote:
With that I am still getting the issues (even with an insance delay of 100
seconds).
Here is the serial log with various runs.
Any thoughts?
Sorry for taking so long to answer but I got a one-week flu and still
had to do my research duties :s
e original
Sujet: Re: nouveau shuts the machine down with v3.9-rc1 (temperature
(72 C) hit the 'shutdown' threshold).
Date : Fri, 15 Mar 2013 11:16:17 -0400
De :Konrad Rzeszutek Wilk
Pour : Martin Peres
On Fri, Mar 15, 2013 at 02:30:44AM +0100, Martin Peres wrote:
sing them
via nv_perfmon ==
Student: Samuel Pitoiset (hakzsam)
Mentor: Martin Peres (mupuf)
Blog: http://hakzsam.wordpress.com/ <https://hakzsam.wordpress.com/>
== Implementing GL_EXT_direct_state_access ==
Student: Dylan Noblesmith
Mentor: Ian Romanick
Proposal:
http://www.cs.usm.maine.
On 07/07/2013 19:17, David Herrmann wrote:
Hi
This is v2 of the unified VMA offset manager series. The first draft is
available at LWN [1]. This series replaces the VMA offset managers in GEM and
TTM with a unified implementation.
The first 4 patches contain the new VMA offset manager and are t
On 11/07/2013 13:21, David Herrmann wrote:
Hi
On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote:
On 07/07/2013 19:17, David Herrmann wrote:
Hi
This is v2 of the unified VMA offset manager series. The first draft is
available at LWN [1]. This series replaces the VMA offset managers in GEM
bca1b44ab4f93216060 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Tue, 26 Oct 2010 12:48:28 +0200
Subject: [PATCH] Fix compilation issues in nouveau_pm when CONFIG_HWMON is not set
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_pm.c |8
1 files changed, 8 ins
Le 03/02/2011 00:42, Alex Deucher a écrit :
We previously used a static array, but some new systems
had more states then we had array space, so dynamically
allocate space based on the number of states in the vbios.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33851
Signed-off-by: Alex De
;t check for CONFIG_HWMON, you may want to ask
them to do so.
Cheers,
Martin
>From 77aee56418ffbb4f0d4683d9e6d9d8d46ad12621 Mon Sep 17 00:00:00 2001
From: Martin Peres
Date: Tue, 12 Oct 2010 03:30:27 +0200
Subject: [PATCH] Try to fix issues when compiling nouveau without CONFIG_HWM
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
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
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.
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
Hi,
Following to my shared talk with krh, danvet and Timoth?e Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for inclus
On 13/12/2012 11:02, Ozan ?a?layan wrote:
> Hi,
>
> I have a geforce 9600gt (nv94) display adapter which has its fan
> running at 100% speed. Yesterday I've compiled and booted with the
> latest nouveau-2.6 tree. sensors from lm_sensors can correctly acquire
> GPU temperature and PWM speed but as f
Hi Nouveau enthusiasts,
One week ago was merged the thermal/fan management code for most nvidia
cards.
So far, no major issue arose but we would like to have more testing as
soon as possible to deliver a nice and solid support when Linux 3.8 is
released.
Thermal management is split into two p
Hi,
Following to my shared talk with krh, danvet and Timoth?e Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for inclus
On 17/12/2012 13:35, Ozan ?a?layan wrote:
>> Hi Ozan,
>>
>> Please have a look at this documentation:
>> http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal
>> It will tell you how to use fan management on your card :)
>>
>> Please report back! I am interested i
Le 18/12/2012 13:03, Daniel Vetter a ?crit :
> On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote:
>> Hi,
>>
>> Following to my shared talk with krh, danvet and Timoth?e Ravier @
>> XDC2012, I have
>> actually taken the time to start fixing some securi
On 19/12/2012 20:39, Ozan ?a?layan wrote:
>> Here you go :)
>>
>> I managed to reproduce the issue. Please test this patch!
> Okay switching to automatic mode when pwm1 == 100 now gradually (in a
> few seconds, it is not cut down to 35 suddenly) lowers it down to 35.
> Switching to automatic mode w
Le 20/12/2012 14:07, Ozan ?a?layan a ?crit :
>> So, we had some discussions within the nouveau community about
>> this and we decided that 0 would mean, no updates on the current status.
>>
>> Anything against it?
> So if I switch automatic mode on and then disable it then do some heavy GPU
> proce
On 21/12/2012 13:04, Ozan ?a?layan wrote:
>> Of course it is, but why would you disable automatic fan management?
>>
>> You are supposed to activate it and let it activated at all time.
> It's not me but someone inexperienced playing with sysfs tunables for example
> :)
Ah, sure. Well, there is d
Le 04/01/2012 08:20, Dan Carpenter a ?crit :
> calc_mclk() returns zero on success and negative on failure but clk is
> a u32.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
> b/drivers/gpu/drm/nouveau/nv50_pm.c
> index 0393721..3508de9 100644
> --- a/drivers/g
Le 10/01/2012 06:39, Dan Carpenter a ?crit :
> On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote:
>> Le 04/01/2012 08:20, Dan Carpenter a ?crit :
>>> calc_mclk() returns zero on success and negative on failure but clk is
>>> a u32.
>>>
>>> Si
Le 03/02/2011 00:42, Alex Deucher a ?crit :
> We previously used a static array, but some new systems
> had more states then we had array space, so dynamically
> allocate space based on the number of states in the vbios.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=33851
>
> Signed-off
Le 11/10/2010 18:29, Randy Dunlap a ?crit :
> When CONFIG_HWMON is not enabled:
>
> drivers/built-in.o: In function `nouveau_pm_fini':
> (.text+0x1c680f): undefined reference to `hwmon_device_unregister'
> drivers/built-in.o: In function `nouveau_hwmon_init':
> nouveau_pm.c:(.text+0x1c6f93): unde
---
drivers/gpu/drm/nouveau/nouveau_pm.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index 1c99c55..74a7d3a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_pm.c
+++ b/drivers/gpu/drm/nou
Le 26/10/2010 01:59, Randy Dunlap a ?crit :
> On Mon, 25 Oct 2010 14:58:34 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Reminder: do not add 2.6.38 destined stuff to linux-next until after
>> 2.6.37-rc1 is released.
>
> drivers/built-in.o: In function `nouveau_hwmon_init':
> nouveau_pm.c:(.text
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index 8ef1d5b..f691661 100644
--- a/drivers/gpu/drm/nouveau
Le 13/03/2014 14:38, Ilia Mirkin a ?crit :
> On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz
> wrote:
>> [ 326.168487] ==
>> [ 326.168491] [ INFO: possible circular locking dependency detected ]
>> [ 326.168496] 3.13.6 #1270 Not tainted
>> [
st to
make badges and plan for the catering.
I am looking forward to seeing you there, if you have any
inquiries/questions,
please send them to me (please also CC: board at foundation.x.org).
Martin Peres
Le 04/06/2012 13:30, Christian K?nig a ?crit :
> On 04.06.2012 10:44, Lauri Kasanen wrote:
>> So the issue is the location of the info, not the format. I'd be more
>> than happy to split it into six files (default_core_clock,
>> current_core_clock...) that each offer just a kHz number, just like
Le 04/06/2012 16:31, Jerome Glisse a ?crit :
>
> I don't think sysfs is the way to go, i am pretty sure that power
> management will change drasticly again in the future especialy btw
> discret and integrated GPU. I would rather have hardware specific
> ioctl.
>
> Cheers,
> Jerome
Any particular id
Le 04/06/2012 17:18, Jerome Glisse a ?crit :
>
> My experience is that things that are true today for GPU, are not
> tomorrow. Yes there will still be clock/voltage, but there could be
> new complete different things, like shutting down block.
IMO, this isn't something the user should ever be aware
Answers inlined.
Le 04/06/2012 19:19, Jerome Glisse a ?crit :
>
> My point is that there is no way for power management to find an API
> that fits all GPU. If i were to do it now, i would have one ioctl
> version for r3xx, one for r5xx, one for r6xx/r7xx, one for r8xx, one
> for r9xx, ... yes ther
On 04.06.2012 20:29, Jerome Glisse wrote:
> On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse wrote:
>>>
>>> Yeah, I get your point as a kernel dev, but I pitty the userspace dev that
>>> will need to figure out how to use all these ioctls and configuration
>>> options.
>> My point there is that we do
On 04.06.2012 21:54, Daniel Vetter wrote:
>
> In i915-land we're trying to make things Just Work. If needed we can
> expose (generation/platform-specific) tunables in sysfs. But on snb and
> later the combination of rc6+gpu turbo (mostly handled all by hw) is
> rather ok, so I don't see anything go
as possible and do so no later
than September 5th!
Thanks,
Martin Peres - On behalf of the board of directors
On 14/04/2014 15:09, Rob Clark wrote:
> On Mon, Apr 14, 2014 at 8:56 AM, Thomas Hellstrom
> wrote:
>> On 04/14/2014 02:41 PM, One Thousand Gnomes wrote:
throw out all GPU memory on master drop and block ioctls requiring
authentication until master becomes active again.
>>> If you have a
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.
CC: Daniel Vetter
Signed-off-by: Martin Peres
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4a44f89..90ad762
Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.
Cc: Ville Syrjälä
Signed--off-by: Martin Peres
---
drivers/gpu/drm/drm_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0e47df4..f5a5f18
Hi, fellow graphics stack developers,
Now that FOSDEM is over, it is time to think about the
Google Summer of Code 2014!
If you would like to propose a project for the GSoC 2014, please
write your proposals at [1], before the 14th of February, in order
to increase our chances of being an accepted
mentor yourself. You can also have a look at the summer of code
ideas wiki page[1] for interesting projects.
Looking forward to seeing which projects will happen for this 2014 edition!
Martin Peres
[1] http://www.x.org/wiki/SummerOfCodeIdeas/
[2] https://www.google-melange.com/gsoc/homepage
mentor yourself. You can also have a look at the summer of code
ideas wiki page[1] for interesting projects.
Looking forward to seeing which projects will happen for this 2014 edition!
Martin Peres
[1] http://www.x.org/wiki/SummerOfCodeIdeas/
[2] https://www.google-melange.com/gsoc/homepage
On 20/12/2013 07:57, Thomas Hellstrom wrote:
> So this is a potential issue that needs to be brought up sooner or later:
>
> Let's say a client is authenticated by the current master.
> Then the master drops, and we have a new master (fast user switching for
> example).
>
> What's the status of the
On 20/12/2013 10:55, Thomas Hellstrom wrote:
> On 12/20/2013 10:31 AM, Martin Peres wrote:
>> On 20/12/2013 07:57, Thomas Hellstrom wrote:
>>> So this is a potential issue that needs to be brought up sooner or
>>> later:
>>>
>>> Let's say a clien
On 31/01/2013 11:53, Laurent Pinchart wrote:
> On Friday 11 January 2013 21:27:03 Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Would anyone be interested in meeting at the FOSDEM to discuss the Common
>> Display Framework ? There will be a CDF meeting at the ELC at the end of
>> February, the FOS
Le 07/01/2013 17:25, Ozan ?a?layan a ?crit :
>> We will be waiting a until one kernel is released before activating fan
>> management by default.
> So these fan stuff will be merged into 3.9?
Yeah, quite likely :)
I see no reasons for us not to. So far, all bugs have been fixed.
, Martin Peres, Peter Hutterer and Stuart Kreitman.
They will continue to serve until their term ends in 2015. Current
directors whose term expires in 2014 are Matthias Hopf, Keith Packard,
Matt Dew, and Alex Deucher.
A director is expected to participate in the bi-weekly IRC meeting to
discuss
On 11/07/2014 03:42, Alexandre Courbot wrote:
> On 07/10/2014 06:50 PM, Mikko Perttunen wrote:
>> Does GK20A itself have any kind of thermal protection capabilities?
>> Upstream SOCTHERM support is not yet available (though I have a driver
>> in my tree), so we are thinking of disabling CPU DVFS on
them
via nv_perfmon ==
Student: Samuel Pitoiset (hakzsam)
Mentor: Martin Peres (mupuf)
Blog: http://hakzsam.wordpress.com/ <https://hakzsam.wordpress.com/>
== Implementing GL_EXT_direct_state_access ==
Student: Dylan Noblesmith
Mentor: Ian Romanick
Proposal:
http://www.cs.usm.maine.
Le 19/11/2013 16:04, Christian K?nig a ?crit :
> So I think the very first step should be to publish everything on the
> appropriate lists, and not try an approach like releasing the kernel
> code first and waiting for it to show up upstream and then try to
> release the userspace code build on
wever
would still advice you to show your interest by providing patches or
participating to our discussions.
Finally, I would like to thank Google again this year for giving us the
opportunity to get new blood to the projects under the X.Org
Foundation's umbrella!
Martin Peres, on behalf of th
way, come back to us when you have selected some areas and then we
can see if someone is interested to mentor those parts.
>
> Thanks,
> Stefan Lance
>
>
> Hi Stefan,
>
> I came across to contact to Martin Peres the last two days, I asked
> him about the project
Hello everyone,
We are 1.5 months away from XDC and 20 days away from the proposals
deadline[1]!
If you did not manage to secure funding from your company but still
think you could benefit the community by giving a talk, we encourage you
to send an email to the board of X.Org with your talk pr
st swap buffers count instead, we
>> introduce the has-buffer-age parameter.
>>
>> Signed-off-by: Chris Wilson
> Reviewed-by: Ian Romanick
>
Reviewed-by: Martin Peres
On 20/01/15 22:49, Ian Romanick wrote:
> On 01/19/2015 03:00 AM, Chris Wilson wrote:
>> Since the introduction of DRI2GetBuffersWithFormat, the old
>> DRI2GetBuffers interface would always recreate all buffers all the time
>> as it was no longer agnostic to the format value being set by the DDXes.
On 07/07/2013 19:17, David Herrmann wrote:
> Hi
>
> This is v2 of the unified VMA offset manager series. The first draft is
> available at LWN [1]. This series replaces the VMA offset managers in GEM and
> TTM with a unified implementation.
>
> The first 4 patches contain the new VMA offset manager
On 11/07/2013 13:21, David Herrmann wrote:
> Hi
>
> On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres
> wrote:
>> On 07/07/2013 19:17, David Herrmann wrote:
>>> Hi
>>>
>>> This is v2 of the unified VMA offset manager series. The first draft is
>>&
On 05/02/2015 11:49, Christian König wrote:
> Am 04.02.2015 um 23:27 schrieb Alex Deucher:
>> 0-255 seems to be the preferred range for the pwm interface.
>>
>> Signed-off-by: Alex Deucher
> Yeah, using 100 on a 8bit pwm timer sounds rather obviously wrong.
>
> Patch is Reviewed-by: Christian Kö
101 - 200 of 205 matches
Mail list logo
