On Wed, Mar 2, 2016 at 12:53 PM, Eric Biggers wrote:
> On Tue, Mar 01, 2016 at 04:59:05PM +0900, Alexandre Courbot wrote:
>>
>> Eric, since you reported the regression on the first version, would you mind
>> trying
>> this one and giving us your Tested-by? I have tested it on dGPU but
>> unfortu
The DMA API has different semantics on different architectures.
Currently on arm64, it can only provide memory from a small pool which
dries up quickly if we attempt to allocate big buffers from it.
Do not consider that option when running on non-x86, since regular TTM
buffers are the (current) be
On non-PCI devices, nobody should really care if the device does not
provide HDMI...
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index 2f2f252e3fb6..c2337f
Registration of the hwmon device will fail on non-PCI systems since
dev->pdev is NULL in that case. Use the more generic drm_device::dev
member that points to the same and is always set no matter the platform.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_hwmon.c | 2 +-
1 file change
https://bugs.freedesktop.org/show_bug.cgi?id=92833
--- Comment #3 from ba...@barrys-emacs.org ---
I can run with kernel 4.4.2-301.fc23.x86_64 and
xorg-x11-drv-nouveau-1.0.12-3.fc23.x86_64 and have not seen this problem.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=86539
Pierre Moreau changed:
What|Removed |Added
Attachment #122019|0 |1
is obsolete|
the macro deals with target specific differences and so we should always use
this
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 12 ++--
drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc | 6 +++---
2 files changed, 9 insertions(+),
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
b/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index 0d5cbeb..3737bd2 100644
---
Signed-off-by: Karol Herbst
Reviewed-by: Martin Peres
---
drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 882 +--
drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
2 files changed, 442 insertions(+), 442 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/pmu/fuc/gk20
Hi Ben,
On 02-03-16 04:23, Ben Skeggs wrote:
On 03/01/2016 09:37 PM, Hans de Goede wrote:
Ok, I've but an mmiotrace of the blob starting with a monitor connected
to the troubesome connector here:
https://fedorapeople.org/~jwrdegoede/mmiotrace.log.xz
And a demmio-ed version (with color e
this series fixes the PMU on falcons v5 which fixes memory recklocking on
kepler2 and would also allow us to enable memory recklocking on maxwell
Karol Herbst (4):
pmu/fuc: fix imm32 for gk208+
pmu/fuc: replace mov+sethi with imm32
pmu/fuc: use the call macro instead of using the call instru
On Wed, Mar 02, 2016 at 12:22:30PM +0900, Alexandre Courbot wrote:
> Without the commit you mentioned, and with CONFIG_DEBUG_SHIRQ enabled,
> do you also see this error? Is it absolutely reproducable?
Yes, I bisected the problem to that individual commit. The problem never occurs
before that comm
https://bugs.freedesktop.org/show_bug.cgi?id=94374
Bug ID: 94374
Summary: transparent window with DRI_PRIME=1, depending on size
of used textures
Product: Mesa
Version: 11.2
Hardware: x86-64 (AMD64)
OS: Linu
https://bugs.freedesktop.org/show_bug.cgi?id=94374
--- Comment #1 from peter.f...@gmx.de ---
Created attachment 122087
--> https://bugs.freedesktop.org/attachment.cgi?id=122087&action=edit
screenshot of the transparent window
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=94374
--- Comment #2 from Karol Herbst ---
It doesn't seem to be transparted (check the window border of the window in the
background. The new window simply contains the the background as the buffer and
moving around won't update the content ;)
--
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=94374
--- Comment #3 from peter.f...@gmx.de ---
Yes, you are right. It's not true transparency. But the window doesn't show the
image rendered by OpenGL.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact
https://bugs.freedesktop.org/show_bug.cgi?id=94374
--- Comment #4 from Karol Herbst ---
well it works for me
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@
https://bugs.freedesktop.org/show_bug.cgi?id=94374
--- Comment #5 from peter.f...@gmx.de ---
Hm, did you try it multiple times with increasing texture sizes? Is there any
other potentially useful information I could provide?
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=91954
--- Comment #8 from Géza Búza ---
Created attachment 122088
--> https://bugs.freedesktop.org/attachment.cgi?id=122088&action=edit
Kernel 4.5-rc6 log of detaching and re-attaching external monitor
A fix is landed in kernel 4.5-rc6 which address
https://bugs.freedesktop.org/show_bug.cgi?id=94374
--- Comment #6 from Karol Herbst ---
I even tried with 2048 multiple times and it always worked (though I had to
wait a little with >=1024). Otherwise I have no idea how to debug such an
issue. I also have kepler gpu, but a GK106, and you a GK107
Because Linux might use bigger pages than the 4K pages to handle those mmio
ioremaps, the kmmio code shouldn't rely on the pade id as it currently does.
Using the memory address instead of the page id let's us lookup how big the
page is and what it's base address is, so that we won't get a page fa
Without this buffer inconsistencies may appear between the CPU
and GPU when using a PCI GPU on an ARM64 board.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/engine/device/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drm/nouveau/nvkm/engine/device/pci.c
b/drm
When using the DMA-API for instmem, we may obtain a write-combined
mapping. For such cases, add a write barrier in
gk20a_instobj_release_dma() to make sure that all writes have reached
memory at this time.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nvkm/subdev/instmem/gk20a.c | 2 ++
1 fil
23 matches
Mail list logo
