Am Dienstag, dem 09.04.2024 um 10:34 +1000 schrieb Dave Airlie:
> From: Dave Airlie
>
> Running a lot of VK CTS in parallel against nouveau, once every
> few hours you might see something like this crash.
>
> BUG: kernel NULL pointer dereference, address: 0008
> PGD 800114e6e067
which is non-trivial to convert.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 -
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
> drivers/gpu/drm/etnaviv/etnaviv_gem.c |
Am Mittwoch, den 06.05.2020, 10:26 -0400 schrieb Ilia Mirkin:
> [please keep list cc'd in your replies]
>
> On Wed, May 6, 2020 at 10:15 AM Milan Buška wrote:
> > [0.00] Linux version 5.6.10-zotac (root@saux) (gcc version 9.3.0
> > (SAUX Aarch64)) #1 SMP PREEMPT Tue May 5 22:16:40 CEST
Hi Arnd,
Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
>
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
>
Am Mittwoch, den 12.07.2017, 23:56 +0200 schrieb Tobias Klausmann:
> This patch brings back the old nouveau_drm_preclose and
> nouveau_drm_postclose
> functions for closing down a drm device
You forgot to state why this is a good idea.
Regards,
Lucas
> Signed-off-by: Tobias Klausmann
in the regular fini calls, as there is nothing much we can do if
the ioctl fails, so better not leak memory.
Signed-off-by: Lucas Stach <d...@lynxeye.de>
---
drivers/gpu/drm/nouveau/nvif/notify.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvif/notif
uevent based fences hold a reference to the fence context,
just like the legacy ones. So they need to drop this reference
in the same way.
Signed-off-by: Lucas Stach <d...@lynxeye.de>
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Am Sonntag, den 26.06.2016, 14:52 +0200 schrieb Thorsten Leemhuis:
> On 24.06.2016 16:19, George Spelvin wrote:
> >
> > Here's a regression you might add.
> Thx, added.
>
Probably the same bug as
https://bugzilla.kernel.org/show_bug.cgi?id=119861 and already fixed in
the last -rc.
Regards,
Am Montag, den 25.01.2016, 18:44 +0900 schrieb Alexandre Courbot:
> nvkm_device_tegra_new initializes the irq member of the Tegra device
> to -1 in order to signal that it is uninitialized. However,
> nvkm_device_tegra_fini tests it against 0 to check whether an IRQ has
> been allocated or not.
, this flag seems to be the right thing to do.
Reviewed-by: Lucas Stach d...@lynxeye.de
---
Patches that take advantage of this in Mesa will follow up shortly. I'd
to make sure the new flag is ok first before also adding it to libdrm.
drm/nouveau/include/uapi/drm/nouveau_drm.h | 1 +
drm/nouveau
Am Montag, den 29.12.2014, 10:49 +0800 schrieb Vince Hsu:
[...]
That's a read fence to assure the post of the previous writes through
Tegra interconnect. (copy-paster from
https://android.googlesource.com/kernel/tegra.git/+/28b107dcb3aa122de8e94e48af548140d519298f)
I see what it does,
Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu:
On 12/24/2014 09:16 PM, Lucas Stach wrote:
Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu:
The Tegra124 and later Tegra SoCs have a sepatate rail gating register
to enable/disable the clamp. The original function
Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu:
This patch adds some missing pieces of the rail gaing/ungating sequence that
can improve the stability in theory.
Signed-off-by: Vince Hsu vin...@nvidia.com
---
drm/nouveau_platform.c | 42
Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu:
The Tegra124 and later Tegra SoCs have a sepatate rail gating register
to enable/disable the clamp. The original function
tegra_powergate_remove_clamping() is not sufficient for the enable
function. So add a new function which is
of
the invalidate overhead especially for userspace suballocated buffers.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
Nouveau mailing list
Nouveau
Am Dienstag, den 24.06.2014, 22:52 +0900 schrieb Alexandre Courbot:
On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach l.st...@pengutronix.de wrote:
Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst:
op 24-06-14 14:23, Alexandre Courbot schreef:
On Tue, Jun 24, 2014 at 7:55 PM
Linux wrote:
On Tue, Jun 24, 2014 at 06:54:26PM +0900, Alexandre Courbot wrote:
From: Lucas Stach d...@lynxeye.de
On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly at the
appropriate places. Introduce two small helpers
Am Montag, den 26.05.2014, 09:45 +0300 schrieb Terje Bergström:
On 23.05.2014 17:40, Alex Courbot wrote:
On 05/23/2014 06:59 PM, Lucas Stach wrote:
So after checking with more knowledgeable people, it turns out this is
the expected behavior on ARM and BAR regions should be mapped uncached
Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot:
On Mon, May 19, 2014 at 7:16 PM, Lucas Stach l.st...@pengutronix.de wrote:
Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot:
On 05/19/2014 06:57 PM, Lucas Stach wrote:
Am Montag, den 19.05.2014, 18:46 +0900
Am Freitag, den 23.05.2014, 18:43 +0900 schrieb Alexandre Courbot:
On 05/23/2014 06:24 PM, Lucas Stach wrote:
Am Freitag, den 23.05.2014, 16:10 +0900 schrieb Alexandre Courbot:
On Mon, May 19, 2014 at 7:16 PM, Lucas Stach l.st...@pengutronix.de
wrote:
Am Montag, den 19.05.2014, 19:06
nouveau is reading back a lot from those
buffers.
Using the write-combining buffer doesn't need any additional
synchronization as it will get flushed on pushbuf kickoff anyways.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http
Am Montag, den 19.05.2014, 16:10 +0900 schrieb Alexandre Courbot:
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
[acour...@nvidia.com: make conditional and platform-friendly]
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drivers/gpu/drm/nouveau
Am Montag, den 19.05.2014, 10:46 +0200 schrieb Thierry Reding:
On Mon, May 19, 2014 at 04:10:57PM +0900, Alexandre Courbot wrote:
From: Lucas Stach d...@lynxeye.de
Signed-off-by: Lucas Stach d...@lynxeye.de
[acour...@nvidia.com: make conditional and platform-friendly]
Signed-off
-default_caching = TTM_PL_FLAG_UNCACHED;
+#else
man-default_caching = TTM_PL_FLAG_WC;
+#endif
break;
case TTM_PL_TT:
if (nv_device(drm-device)-card_type = NV_50)
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions
/nvidia,gk20a.txt
create mode 100644 drivers/gpu/drm/nouveau/nouveau_platform.c
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
___
Nouveau mailing list
Nouveau
Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot:
On 05/19/2014 06:57 PM, Lucas Stach wrote:
Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot:
This patch is not meant to be merged, but rather to try and understand
why this is needed and what a more suitable
Hi Alexandre,
Am Mittwoch, den 26.03.2014, 15:33 +0900 schrieb Alexandre Courbot:
Hi Lucas,
On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach l.st...@pengutronix.de wrote:
Hi Alexandre,
Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
Hi everyone,
[...]
A few lines
the perf increase may be even better with a more
adequate interconnect.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121
Hi,
recently we tried to enable MSI interrupts with nouveau. Unfortunately
there have been some reports of things failing with certain cards, where
it isn't entirely clear if this is a GPU errata or some other component
in the PCIe chain failing.
Could you perhaps investigate if there are any
, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu
wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de
wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time
Am Mittwoch, den 28.08.2013, 17:11 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace
Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk:
On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote:
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
2 files
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm
to hint the
kernel about possible optimizations.
Lucas Stach (6):
drm/ttm: recognize ARM arch in ioprot handler
drm/ttm: introduce dma cache sync helpers
drm/nouveau: hook up cache sync functions
drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
drm/nouveau: map IB write-combined
drm/nouveau: use
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index af20fba..f4a2eb9 100644
This flag allows userspace to give the kernel a hint that it should use
a non-snooped resource. To guarantee coherency at all times mappings
into userspace are done write combined, so userspace should avoid
reading back from those resources.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
On x86
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 319cf41..db15687 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e84f4c3..3b54e8f 100644
--- a/drivers/gpu/drm/nouveau
On arches with non-coherent PCI, we need to flush caches ourselfes at
the appropriate places. Introduce two small helpers to make things easy
for TTM based drivers.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/ttm/ttm_tt.c| 25 +
include/drm/ttm
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov:
New -rc1, so let the stabilization games begin.
I see the following on rc1, let me know
All HW buffers (also suballocated ones) are already aligned.
Just make sure that also the initial sysram buffers have proper
alignment.
---
Passes the ARB_map_buffer_alignment piglit test on nv50.
Not tested on nvc0.
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 6 +++---
anything:
Reviewed-by: Lucas Stach d...@lynxeye.de
---
Note: This patch is only for the 8.0 branch.
Compile tested only.
src/gallium/drivers/nvfx/nvfx_screen.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c
b/src/gallium
---
configure.ac| 1 +
src/gallium/drivers/nouveau/Makefile| 16
src/gallium/drivers/nouveau/Makefile.am | 16
3 Dateien ge??ndert, 17 Zeilen hinzugef??gt(+), 16 Zeilen entfernt(-)
delete mode 100644
Trivial series to convert Nouveau gallium drivers to automake
in order to generate Makefiles.
This is just the general direction in which the MESA buildsystem
is moving. Aside from this it makes the make output a lot more
readable and therefore helps to spot compiler warnings more easily.
Lucas
---
configure.ac | 1 +
src/gallium/drivers/nv30/Makefile| 12
src/gallium/drivers/nv30/Makefile.am | 16
3 Dateien ge??ndert, 17 Zeilen hinzugef??gt(+), 12 Zeilen entfernt(-)
delete mode 100644 src/gallium/drivers/nv30/Makefile
create
---
configure.ac | 1 +
src/gallium/drivers/nv50/Makefile| 12
src/gallium/drivers/nv50/Makefile.am | 25 +
3 Dateien ge??ndert, 26 Zeilen hinzugef??gt(+), 12 Zeilen entfernt(-)
delete mode 100644 src/gallium/drivers/nv50/Makefile
---
configure.ac | 1 +
src/gallium/drivers/nvc0/Makefile| 12
src/gallium/drivers/nvc0/Makefile.am | 25 +
3 Dateien ge??ndert, 26 Zeilen hinzugef??gt(+), 12 Zeilen entfernt(-)
delete mode 100644 src/gallium/drivers/nvc0/Makefile
One minor nitpick inline, otherwise:
Reviewed-by: Lucas Stach d...@lynxeye.de
Tested-by: Lucas Stach d...@lynxeye.de on nv49 and nv35
Am Montag, den 09.07.2012, 23:15 +0200 schrieb Roy Spliet:
Fixes piglit vp-address-01 amongst several others
Signed-off-by: Roy Spliet r.spl
Fixes an assertion seen by users.
Signed-off-by: Lucas Stach d...@lynxeye.de
Tested-by: JohnDoe_71Rus on irc
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c
b/src/mesa/drivers/dri
And I managed to hit reply privately two times in a row. -.-
Am Montag, den 30.04.2012, 20:22 +0200 schrieb Lucas Stach:
Am Montag, den 30.04.2012, 20:08 +0200 schrieb Francisco Jerez:
Lucas Stach d...@lynxeye.de writes:
Fixes an assertion seen by users.
Signed-off-by: Lucas Stach
Am Montag, den 30.04.2012, 21:42 +0200 schrieb Francisco Jerez:
Lucas Stach d...@lynxeye.de writes:
Am Montag, den 30.04.2012, 20:08 +0200 schrieb Francisco Jerez:
Lucas Stach d...@lynxeye.de writes:
[...]
+/* only advertise supported texture formats */
+memset(ctx
From: Mario Kleiner mario.klei...@tuebingen.mpg.de
Emit kms pageflip completion events with proper vblank count
and timestamp for the vblank interval in which the pageflip
completed. This makes the timestamps and counts consistent with
what the OML_sync_control spec defines.
v2 Lucas Stach
to moved regs.
Kudos to Mario for his many helpful comments and testing.
Signed-off-by: Lucas Stach d...@lynxeye.de
Reviewed-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
Tested-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
drivers/gpu/drm/nouveau/nouveau_display.c | 25
Just updated versions of the patches send by Mario Kleiner. This ones are
rebased on top of the nouveau tree and updated according to the review
feedback.
This time hopefully the right ones.
Regards,
Lucas
___
Nouveau mailing list
From: Mario Kleiner mario.klei...@tuebingen.mpg.de
Emit kms pageflip completion events with proper vblank count
and timestamp for the vblank interval in which the pageflip
completed. This makes the timestamps and counts consistent with
what the OML_sync_control spec defines.
v2 Lucas Stach
to OML_sync_control spec)
v2: Rebase on top of nouveau tree and update to reflect Ben's
review feedback.
Kudos to Mario for his many helpful comments and testing.
Signed-off-by: Lucas Stach d...@lynxeye.de
Reviewed-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
Tested-by: Mario Kleiner mario.klei
Just updated versions of the patches send by Mario Kleiner. This ones are
rebased on top of the nouveau tree and updated according to the review
feedback.
Regards,
Lucas
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
From: Mario Kleiner mario.klei...@tuebingen.mpg.de
Emit kms pageflip completion events with proper vblank count
and timestamp for the vblank interval in which the pageflip
completed. This makes the timestamps and counts consistent with
what the OML_sync_control spec defines.
v2 Lucas Stach
to OML_sync_control spec)
v2: Rebase on top of nouveau tree and update to reflect Ben's
review feedback.
Kudos to Mario for his many helpful comments and testing.
Signed-off-by: Lucas Stach d...@lynxeye.de
Reviewed-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
Tested-by: Mario Kleiner mario.klei
Ignore this, apparently git send-email messed up and relayed the old
patches. WTF?
Am Freitag, den 17.02.2012, 00:28 +0100 schrieb Lucas Stach:
Just updated versions of the patches send by Mario Kleiner. This ones are
rebased on top of the nouveau tree and updated according to the review
Am Donnerstag, den 26.01.2012, 20:59 +0100 schrieb Patrice Mandin:
Le Tue, 24 Jan 2012 09:54:31 +0100
Lucas Stach d...@lynxeye.de a écrit:
From c998f732d42da5e962fe5da294493132c3e8dc5f Mon Sep 17 00:00:00 2001
From: Lucas Stach d...@lynxeye.de
Date: Tue, 24 Jan 2012 09:46:32 +0100
From c998f732d42da5e962fe5da294493132c3e8dc5f Mon Sep 17 00:00:00 2001
From: Lucas Stach d...@lynxeye.de
Date: Tue, 24 Jan 2012 09:46:32 +0100
Subject: [PATCH] nvfx: fix nv3x fallout from state validation changes
Apparently nv3x needs some curde hacks to work properly. This
is clearly
Am Mittwoch, den 18.01.2012, 21:54 +0100 schrieb Patrice Mandin:
Le Tue, 17 Jan 2012 18:22:59 +0100
Patrice Mandin mandin.patr...@orange.fr a écrit:
Le Tue, 10 Jan 2012 12:41:04 +0100
Lucas Stach d...@lynxeye.de a écrit:
Signed-off-by: Lucas Stach d...@lynxeye.de
---
src
Am Dienstag, den 17.01.2012, 18:22 +0100 schrieb Patrice Mandin:
Le Tue, 10 Jan 2012 12:41:04 +0100
Lucas Stach d...@lynxeye.de a écrit:
Signed-off-by: Lucas Stach d...@lynxeye.de
---
src/gallium/drivers/nvfx/nvfx_state_emit.c | 49
---
1 files changed, 22
schrieb Lucas Stach:
Am Samstag, den 14.01.2012, 13:14 +0100 schrieb Patrice Mandin:
Hello,
I just tried on my NV34 the whole series. Here is what I noticed:
Thanks for testing. Although now after some discussion it seems unlikely
that we will see much of this in nvfx it really helps me
Am Samstag, den 14.01.2012, 13:14 +0100 schrieb Patrice Mandin:
Hello,
I just tried on my NV34 the whole series. Here is what I noticed:
Thanks for testing. Although now after some discussion it seems unlikely
that we will see much of this in nvfx it really helps me to decide if i
can go this
nvfx doesn't support any kind of stream out, so silence the
unused cap warnings.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
src/gallium/drivers/nvfx/nvfx_screen.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c
b/src
Signed-off-by: Lucas Stach d...@lynxeye.de
---
src/gallium/drivers/nvfx/nvfx_state_emit.c | 49 ---
1 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c
b/src/gallium/drivers/nvfx/nvfx_state_emit.c
index e2cfb76
Ping.
Could someone with knowledge in this area please review this patch, to
see if it is acceptable? I would really like to see this patch landing
in the nouveau git repo as soon as Mario comes around to retest it.
Thanks,
Lucas
Am Donnerstag, den 24.11.2011, 01:53 +0100 schrieb Lucas Stach
to OML_sync_control spec)
Kudos to Mario for his many helpful comments and testing.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
Please review.
Mario: Could you please get it another go? I fixed up coding style
in many places, hope I didn't break anything.
---
drivers/gpu/drm/nouveau/nouveau_display.c
Am Mittwoch, den 20.04.2011, 00:59 +0200 schrieb Hanno Böck:
Hi,
Nvidia produces the tegra SoC-systems, a popular use is the toshiba
ac100.
These devices have an internal graphics chip, one can get a driver from
nvidia, but as you can guess, it's proprietary only.
I don't have any idea
Am Dienstag, den 08.03.2011, 08:22 +1000 schrieb Ben Skeggs:
The *other* possible thing is that the ttm delayed delete queue is
causing multiple tlb flushes to happen at the same time. I'll add
locking for that in the morning, that was a complete oversight.
I've had no lockups
Just adding a me too.
I updated from 3fdb729eb7de5597961eb3fbaf0bdfe6f4262307 and now I get
lockups from time to time (max. 60 mins) with normal 2D desktop usage.
No 3D involved here.
Logs only contain:
Mar 6 17:27:51 workstation kernel: [ 341.970412] [drm] nouveau
:01:00.0: PGRAPH -
Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres:
Le 03/03/2011 16:22, Guenter Roeck a écrit :
On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote:
On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvarekh...@linux-fr.org wrote:
On Sun, 13 Feb 2011 09:16:40 -0800, Guenter
Am Donnerstag, den 03.03.2011, 13:19 -0800 schrieb Guenter Roeck:
On Thu, 2011-03-03 at 15:48 -0500, Lucas Stach wrote:
Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres:
Le 03/03/2011 16:22, Guenter Roeck a écrit :
On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie
Hi Ben,
please push. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=33434 where I messed up.
-- Lucas
From 996f1a11521a1b5b71e82b24e388a03f2f7ae2c2 Mon Sep 17 00:00:00 2001
From: Lucas Stach d...@lynxeye.de
Date: Sun, 30 Jan 2011 10:54:11 +0100
Subject: [PATCH] drm/nouveau: correctly
: Lucas Stach d...@lynxeye.de
Date: Wed, 5 Jan 2011 22:41:24 +0100
Subject: [PATCH 1/2] drm/nouveau: change temp sensor defaults to neutral ones
The hardcoded slope and offset defaults in nouveau are not really
defaults, as they are retrieved from some random vbioses. So they
are likely wrong
The following patch fixes the creation directory of the hwmon files, to
get our directory hierarchy in line with all other hwmon drivers.
--lynxeye
From b29a9259cbc6f88f83d7162e88f89f9345c1be3d Mon Sep 17 00:00:00 2001
From: Lucas Stach d...@lynxeye.de
Date: Thu, 6 Jan 2011 20:29:53 +0100
Subject
Hi all,
I want to bring up this issue again on the mailing list, since it got
lost in some irc chat a few days ago.
Deadwood came to the channel and noted that
25ee1f0e25195729f28b15f33d74db9ec6afd696 removes support for
NOUVEAU_GEM_CPU_PREP_NOBLOCK in the kernel. This renders nouveau_bo_busy
I would really like to test your patch on nv47, but it doesn't apply to
current master. It seems to be fixable manually, as only the line
numbers in the diff are wrong, but i wonder what's the reason for this.
-- lynxeye
Am Montag, den 20.12.2010, 22:58 +0100 schrieb Xavier Chantry:
I don't
Ok, so some people including me just misunderstood the commit. Thanks
for the enlightenment.
-- lynxeye
Am Montag, den 20.12.2010, 22:39 +0100 schrieb Francisco Jerez:
Lucas Stach d...@lynxeye.de writes:
Hi all,
I want to bring up this issue again on the mailing list, since it got
Hi Michel,
had a short look on this, as far as i can tell at the time the patch
looks fairly good and we really need this checks.
Some small notes:
1. In loops with fixed iterations the WAIT_RING should be called before
the loop, not inside. I think it is ok if we waste a few pushbuf entries
to
Attached a trivial fix for mesa/nvfx to shut up warnings about unknown
pipe caps.
-- Lucas
From da05bfedcf0e26c454fe227b33f20875666fdda6 Mon Sep 17 00:00:00 2001
From: Lucas Stach d...@lynxeye.de
Date: Wed, 10 Nov 2010 23:03:03 +0100
Subject: [PATCH] nvfx: fill PIPE_CAP_PRIMITIVE_RESTART
Hi Francesco,
you have most probably a hardware defect. Either your vram is defunct or
your gpu has a bounding problem, which is not uncommon on nv50 class
laptop chips.
So I think it doesn't make sense to search a bug on the nouveau side.
-- Lucas
Am Freitag, den 05.11.2010, 13:59 +0100
Oh, yes. It seems my email client had some good lunch with the tabs.
I added the patch as an attachment. Hope it works this time.
-- Lucas
Am Montag, den 18.10.2010, 15:47 +0200 schrieb Francisco Jerez:
Lucas Stach d...@lynxeye.de writes:
Nouveau sets GART size to 64MiB for all cards
Nouveau sets GART size to 64MiB for all cards before nv50, but nv40 has
enough RAMIN space to support 512MiB GART size. This patch fixes this
value to make use of this hardware capability.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |6 +-
1 files
87 matches
Mail list logo
