Re: [Nouveau] [PATCH v2] Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

2016-06-06 Thread Alexandre Courbot 
On Mon, Jun 6, 2016 at 6:25 PM, Robin Murphy  wrote:
> On 06/06/16 08:11, Alexandre Courbot wrote:
>>
>> From: Robin Murphy 
>>
>> This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50.
>>
>> There is apparently something amiss with the way the TTM code handles
>> DMA buffers, which the above commit was attempting to work around for
>> arm64 systems with non-coherent PCI. Unfortunately, this completely
>> breaks systems *with* coherent PCI (which appear to be the majority).
>>
>> Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
>> a machine with a PCI GPU having coherent dma_map_ops (in this case a
>> 7600GT card plugged into an ARM Juno board) results in a fatal crash:
>>
>> [2.803438] nouveau :06:00.0: DRM: allocated 1024x768 fb: 0x9000,
>> bo ffc976141c00
>> [2.897662] Unable to handle kernel NULL pointer dereference at virtual
>> address 01ac
>> [2.897666] pgd = ff8008e0
>> [2.897675] [01ac] *pgd=0009e003, *pud=0009e003,
>> *pmd=
>> [2.897680] Internal error: Oops: 9645 [#1] PREEMPT SMP
>> [2.897685] Modules linked in:
>> [2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
>> [2.897694] Hardware name: ARM Juno development board (r1) (DT)
>> [2.897699] task: ffc9768a ti: ffc9768a8000 task.ti:
>> ffc9768a8000
>> [2.897711] PC is at __memcpy+0x7c/0x180
>> [2.897719] LR is at OUT_RINGp+0x34/0x70
>> [2.897724] pc : [] lr : [] pstate:
>> 8045
>> [2.897726] sp : ffc9768ab360
>> [2.897732] x29: ffc9768ab360 x28: 0001
>> [2.897738] x27: ffc97624c000 x26: 
>> [2.897744] x25: 0080 x24: 6c00
>> [2.897749] x23: 0005 x22: ffc97624c010
>> [2.897755] x21: 0004 x20: 0004
>> [2.897761] x19: ffc9763da000 x18: ffc976b2491c
>> [2.897766] x17: 0007 x16: 0006
>> [2.897771] x15: 0001 x14: 0001
>> [2.89] x13: 00e31b70 x12: ffc9768a0080
>> [2.897783] x11:  x10: fb00
>> [2.897788] x9 :  x8 : 
>> [2.897793] x7 :  x6 : 01ac
>> [2.897799] x5 :  x4 : 
>> [2.897804] x3 : 0010 x2 : 0010
>> [2.897810] x1 : ffc97624c010 x0 : 01ac
>> ...
>> [2.898494] Call trace:
>> [2.898499] Exception stack(0xffc9768ab1a0 to 0xffc9768ab2c0)
>> [2.898506] b1a0: ffc9763da000 0004 ffc9768ab360
>> ff80083465fc
>> [2.898513] b1c0: ffc976801e00 ffc9762b8000 ffc9768ab1f0
>> ff80080ec158
>> [2.898520] b1e0: ffc9768ab230 ff8008496d04 ffc975ce6d80
>> ffc9768ab36e
>> [2.898527] b200: ffc9768ab36f ffc9768ab29d ffc9768ab29e
>> ffc9768a
>> [2.898533] b220: ffc9768ab250 ff80080e70c0 ffc9768ab270
>> ff8008496e44
>> [2.898540] b240: 01ac ffc97624c010 0010
>> 0010
>> [2.898546] b260:   01ac
>> 
>> [2.898552] b280:   fb00
>> 
>> [2.898558] b2a0: ffc9768a0080 00e31b70 0001
>> 0001
>> [2.898566] [] __memcpy+0x7c/0x180
>> [2.898574] [] nv04_fbcon_imageblit+0x1d4/0x2e8
>> [2.898582] [] nouveau_fbcon_imageblit+0xd8/0xe0
>> [2.898591] [] soft_cursor+0x154/0x1d8
>> [2.898598] [] bit_cursor+0x4fc/0x538
>> [2.898605] [] fbcon_cursor+0x134/0x1a8
>> [2.898613] [] hide_cursor+0x38/0xa0
>> [2.898620] [] redraw_screen+0x120/0x228
>> [2.898628] [] fbcon_prepare_logo+0x370/0x3f8
>> [2.898635] [] fbcon_init+0x350/0x560
>> [2.898641] [] visual_init+0xac/0x108
>> [2.898648] [] do_bind_con_driver+0x1c4/0x3a8
>> [2.898655] [] do_take_over_console+0x174/0x1e8
>> [2.898662] [] do_fbcon_takeover+0x74/0x100
>> [2.898669] [] fbcon_event_notify+0x8cc/0x920
>> [2.898680] [] notifier_call_chain+0x50/0x90
>> [2.898685] []
>> __blocking_notifier_call_chain+0x4c/0x90
>> [2.898691] [] blocking_notifier_call_chain+0x14/0x20
>> [2.898696] [] fb_notifier_call_chain+0x1c/0x28
>> [2.898703] [] register_framebuffer+0x1cc/0x2e0
>> [2.898712] []
>> drm_fb_helper_initial_config+0x288/0x3e8
>> [2.898719] [] nouveau_fbcon_init+0xe0/0x118
>> [2.898727] [] nouveau_drm_load+0x268/0x890
>> [2.898734] [] drm_dev_register+0xbc/0xc8
>> [2.898740] [] drm_get_pci_dev+0xa0/0x180
>> [2.898747] [] nouveau_drm_probe+0x1a0/0x1e0
>> [2.898755] [] pci_device_probe+0x98/0x110
>> [2.898763] [] driver_probe_device+0x204/0x2b0
>> [2.898770] [] __driver_attach+0xac/0xb0
>> [

[Nouveau] [Bug 96411] [NVA8] reclocking not working. screen glitches.

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96411

Roy  changed:

   What|Removed |Added

   Assignee|nouveau@lists.freedesktop.o |nouv...@spliet.org
   |rg  |

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 96411] [NVA8] reclocking not working. screen glitches.

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96411

--- Comment #3 from J. Neto  ---
Created attachment 124372
  --> https://bugs.freedesktop.org/attachment.cgi?id=124372=edit
nouveau kmsgs

In the boot after the bug I've run: journalctl -b -1 -o cat | grep nouveau

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 96411] [NVA8] reclocking not working. screen glitches.

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96411

--- Comment #2 from J. Neto  ---
Created attachment 124371
  --> https://bugs.freedesktop.org/attachment.cgi?id=124371=edit
mmio trace

in: uname -a
out: Linux t410 4.4.9-300.fc23.x86_64 #1 SMP Mon Feb 1 03:18:41 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux

in: ???
out: nvidia-340xx-340.96

I've followed this guide: https://wiki.ubuntu.com/X/MMIOTracing

And during the tracing I've run: xinit -e sh -c "glxgears & sleep 10"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 96411] [NVA8] reclocking not working. screen glitches.

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96411

--- Comment #1 from J. Neto  ---
Created attachment 124370
  --> https://bugs.freedesktop.org/attachment.cgi?id=124370=edit
NVS 3100m vbios dump

in: nvapeek 0x101000
out: 00101000: 8f78b098

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 96411] New: [NVA8] reclocking not working. screen glitches.

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96411

Bug ID: 96411
   Summary: [NVA8] reclocking not working. screen glitches.
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: josenetodino+freedesk...@gmail.com
QA Contact: xorg-t...@lists.x.org

Reclocking isn't working in linux 4.4 and 4.5, 4.3 is ok. I didn't test linux
4.6. 

Right after echo 03 > pstate the screen glitches, but I'm able to safe reboot
by sysrq method.

There are no errors on the log.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 11/14] drm/nouveau: use drm_crtc_vblank_{get, put}()

2016-06-06 Thread Gustavo Padovan 
From: Gustavo Padovan 

Replace the legacy drm_vblank_{get,put}() with the new helper functions.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 9d72467..7898459f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -764,7 +764,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
  new_bo->bo.offset };
 
/* Keep vblanks on during flip, for the target crtc of this flip */
-   drm_vblank_get(dev, nouveau_crtc(crtc)->index);
+   drm_crtc_vblank_get(crtc);
 
/* Emit a page flip */
if (drm->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
@@ -809,7 +809,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
return 0;
 
 fail_unreserve:
-   drm_vblank_put(dev, nouveau_crtc(crtc)->index);
+   drm_crtc_vblank_put(crtc);
ttm_bo_unreserve(_bo->bo);
 fail_unpin:
mutex_unlock(>mutex);
@@ -847,12 +847,12 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
drm_crtc_send_vblank_event(s->crtc, s->event);
 
/* Give up ownership of vblank for page-flipped crtc */
-   drm_vblank_put(dev, drm_crtc_index(s->crtc));
+   drm_crtc_vblank_put(s->crtc);
}
}
else {
/* Give up ownership of vblank for page-flipped crtc */
-   drm_vblank_put(dev, drm_crtc_index(state->crtc));
+   drm_crtc_vblank_put(state->crtc);
}
 
list_del(>head);
-- 
2.5.5

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC v3 44/45] dma-mapping: Remove dma_get_attr

2016-06-06 Thread Hans-Christian Noren Egtvedt 
Around Thu 02 Jun 2016 17:39:46 +0200 or thereabout, Krzysztof Kozlowski wrote:
> After switching DMA attributes to unsigned long it is easier to just
> compare the bits.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/DMA-API.txt  |  4 +--
>  arch/arc/mm/dma.c  |  4 +--
>  arch/arm/mm/dma-mapping.c  | 36 
> --
>  arch/arm/xen/mm.c  |  4 +--
>  arch/arm64/mm/dma-mapping.c| 10 +++
>  arch/avr32/mm/dma-coherent.c   |  4 +--

For the AVR32 related change

Acked-by: Hans-Christian Noren Egtvedt 

>  arch/ia64/sn/pci/pci_dma.c | 10 ++-
>  arch/metag/kernel/dma.c|  2 +-
>  arch/mips/mm/dma-default.c |  6 ++---
>  arch/openrisc/kernel/dma.c |  4 +--
>  arch/parisc/kernel/pci-dma.c   |  2 +-
>  arch/powerpc/platforms/cell/iommu.c| 10 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  2 +-
>  drivers/iommu/dma-iommu.c  |  2 +-
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
>  include/linux/dma-mapping.h| 13 --
>  16 files changed, 46 insertions(+), 69 deletions(-)



> diff --git a/arch/avr32/mm/dma-coherent.c b/arch/avr32/mm/dma-coherent.c
> index fc51f4421933..58610d0df7ed 100644
> --- a/arch/avr32/mm/dma-coherent.c
> +++ b/arch/avr32/mm/dma-coherent.c
> @@ -109,7 +109,7 @@ static void *avr32_dma_alloc(struct device *dev, size_t 
> size,
>   return NULL;
>   phys = page_to_phys(page);
>  
> - if (dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs)) {
> + if (attrs & DMA_ATTR_WRITE_COMBINE) {
>   /* Now, map the page into P3 with write-combining turned on */
>   *handle = phys;
>   return __ioremap(phys, size, _PAGE_BUFFER);
> @@ -123,7 +123,7 @@ static void avr32_dma_free(struct device *dev, size_t 
> size,
>  {
>   struct page *page;
>  
> - if (dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs)) {
> + if (attrs & DMA_ATTR_WRITE_COMBINE) {
>   iounmap(cpu_addr);
>  
>   page = phys_to_page(handle);



-- 
mvh
Hans-Christian Noren Egtvedt
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC v3 07/45] avr32: dma-mapping: Use unsigned long for dma_attrs

2016-06-06 Thread Hans-Christian Noren Egtvedt 
Around Thu 02 Jun 2016 17:39:09 +0200 or thereabout, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Hans-Christian Noren Egtvedt 

> ---
>  arch/avr32/mm/dma-coherent.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/avr32/mm/dma-coherent.c b/arch/avr32/mm/dma-coherent.c
> index 92cf1fb2b3e6..fc51f4421933 100644
> --- a/arch/avr32/mm/dma-coherent.c
> +++ b/arch/avr32/mm/dma-coherent.c
> @@ -99,7 +99,7 @@ static void __dma_free(struct device *dev, size_t size,
>  }
>  
>  static void *avr32_dma_alloc(struct device *dev, size_t size,
> - dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
> + dma_addr_t *handle, gfp_t gfp, unsigned long attrs)
>  {
>   struct page *page;
>   dma_addr_t phys;
> @@ -119,7 +119,7 @@ static void *avr32_dma_alloc(struct device *dev, size_t 
> size,
>  }
>  
>  static void avr32_dma_free(struct device *dev, size_t size,
> - void *cpu_addr, dma_addr_t handle, struct dma_attrs *attrs)
> + void *cpu_addr, dma_addr_t handle, unsigned long attrs)
>  {
>   struct page *page;
>  
> @@ -142,7 +142,7 @@ static void avr32_dma_free(struct device *dev, size_t 
> size,
>  
>  static dma_addr_t avr32_dma_map_page(struct device *dev, struct page *page,
>   unsigned long offset, size_t size,
> - enum dma_data_direction direction, struct dma_attrs *attrs)
> + enum dma_data_direction direction, unsigned long attrs)
>  {
>   void *cpu_addr = page_address(page) + offset;
>  
> @@ -152,7 +152,7 @@ static dma_addr_t avr32_dma_map_page(struct device *dev, 
> struct page *page,
>  
>  static int avr32_dma_map_sg(struct device *dev, struct scatterlist *sglist,
>   int nents, enum dma_data_direction direction,
> - struct dma_attrs *attrs)
> + unsigned long attrs)
>  {
>   int i;
>   struct scatterlist *sg;
-- 
mvh
Hans-Christian Noren Egtvedt
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 01/14] drm/nouveau: use drm_crtc_send_vblank_event() v2

2016-06-06 Thread Daniel Vetter 
On Mon, Jun 06, 2016 at 11:41:32AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Replace the legacy drm_send_vblank_event() with the new helper function.
> 
> v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner)
> 
> Cc: Mario Kleiner 
> Signed-off-by: Gustavo Padovan 

Forgot to squash this into the main nouveau patch as fixup?
-Daniel

> ---
>  drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>  drivers/gpu/drm/nouveau/nouveau_display.h |  3 ++-
>  2 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 7c77f96..9d72467 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -760,8 +760,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
> drm_framebuffer *fb,
>  
>   /* Initialize a page flip struct */
>   *s = (struct nouveau_page_flip_state)
> - { { }, event, nouveau_crtc(crtc)->index,
> -   fb->bits_per_pixel, fb->pitches[0], crtc->x, crtc->y,
> + { { }, event, crtc, fb->bits_per_pixel, fb->pitches[0],
> new_bo->bo.offset };
>  
>   /* Keep vblanks on during flip, for the target crtc of this flip */
> @@ -842,17 +841,18 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
>   s = list_first_entry(>flip, struct nouveau_page_flip_state, head);
>   if (s->event) {
>   if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA) {
> - drm_arm_vblank_event(dev, s->crtc, s->event);
> + drm_arm_vblank_event(dev, drm_crtc_index(s->crtc),
> +  s->event);
>   } else {
> - drm_send_vblank_event(dev, s->crtc, s->event);
> + drm_crtc_send_vblank_event(s->crtc, s->event);
>  
>   /* Give up ownership of vblank for page-flipped crtc */
> - drm_vblank_put(dev, s->crtc);
> + drm_vblank_put(dev, drm_crtc_index(s->crtc));
>   }
>   }
>   else {
>   /* Give up ownership of vblank for page-flipped crtc */
> - drm_vblank_put(dev, s->crtc);
> + drm_vblank_put(dev, drm_crtc_index(state->crtc));
>   }
>  
>   list_del(>head);
> @@ -873,9 +873,10 @@ nouveau_flip_complete(struct nvif_notify *notify)
>  
>   if (!nouveau_finish_page_flip(chan, )) {
>   if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA) {
> - nv_set_crtc_base(drm->dev, state.crtc, state.offset +
> -  state.y * state.pitch +
> -  state.x * state.bpp / 8);
> + nv_set_crtc_base(drm->dev, drm_crtc_index(state.crtc),
> +  state.offset + state.crtc->y *
> +  state.pitch + state.crtc->x *
> +  state.bpp / 8);
>   }
>   }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h 
> b/drivers/gpu/drm/nouveau/nouveau_display.h
> index 24273ba..0420ee8 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.h
> @@ -28,7 +28,8 @@ int nouveau_framebuffer_init(struct drm_device *, struct 
> nouveau_framebuffer *,
>  struct nouveau_page_flip_state {
>   struct list_head head;
>   struct drm_pending_vblank_event *event;
> - int crtc, bpp, pitch, x, y;
> + struct drm_crtc *crtc;
> + int bpp, pitch;
>   u64 offset;
>  };
>  
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Donate NVS 510 and 310 cards

2016-06-06 Thread Ed Avis 
Hi, I have some spare Nvidia NVS 310 cards (with two DP1.2 outputs) and at
least one NVS 510 (four DP1.2 outputs).  Would any Nouveau developer like to
accept some as a donation?

-- 
Ed Avis 

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 95054] KDE 5 / Plasma crashes with nouveau "fifo: gr engine fault on channel 2, recovering" or "gr: TRAP ch 2"

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=95054

--- Comment #8 from René Krell  ---
The bug discussed here still happens with kernel 4.6.0 but very rarely, while
in 4.5.4 it happened reliably after a few minutes of using Chromium.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

2016-06-06 Thread Robin Murphy 

On 06/06/16 08:11, Alexandre Courbot wrote:

From: Robin Murphy 

This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50.

There is apparently something amiss with the way the TTM code handles
DMA buffers, which the above commit was attempting to work around for
arm64 systems with non-coherent PCI. Unfortunately, this completely
breaks systems *with* coherent PCI (which appear to be the majority).

Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
a machine with a PCI GPU having coherent dma_map_ops (in this case a
7600GT card plugged into an ARM Juno board) results in a fatal crash:

[2.803438] nouveau :06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo 
ffc976141c00
[2.897662] Unable to handle kernel NULL pointer dereference at virtual 
address 01ac
[2.897666] pgd = ff8008e0
[2.897675] [01ac] *pgd=0009e003, *pud=0009e003, 
*pmd=
[2.897680] Internal error: Oops: 9645 [#1] PREEMPT SMP
[2.897685] Modules linked in:
[2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
[2.897694] Hardware name: ARM Juno development board (r1) (DT)
[2.897699] task: ffc9768a ti: ffc9768a8000 task.ti: 
ffc9768a8000
[2.897711] PC is at __memcpy+0x7c/0x180
[2.897719] LR is at OUT_RINGp+0x34/0x70
[2.897724] pc : [] lr : [] pstate: 
8045
[2.897726] sp : ffc9768ab360
[2.897732] x29: ffc9768ab360 x28: 0001
[2.897738] x27: ffc97624c000 x26: 
[2.897744] x25: 0080 x24: 6c00
[2.897749] x23: 0005 x22: ffc97624c010
[2.897755] x21: 0004 x20: 0004
[2.897761] x19: ffc9763da000 x18: ffc976b2491c
[2.897766] x17: 0007 x16: 0006
[2.897771] x15: 0001 x14: 0001
[2.89] x13: 00e31b70 x12: ffc9768a0080
[2.897783] x11:  x10: fb00
[2.897788] x9 :  x8 : 
[2.897793] x7 :  x6 : 01ac
[2.897799] x5 :  x4 : 
[2.897804] x3 : 0010 x2 : 0010
[2.897810] x1 : ffc97624c010 x0 : 01ac
...
[2.898494] Call trace:
[2.898499] Exception stack(0xffc9768ab1a0 to 0xffc9768ab2c0)
[2.898506] b1a0: ffc9763da000 0004 ffc9768ab360 
ff80083465fc
[2.898513] b1c0: ffc976801e00 ffc9762b8000 ffc9768ab1f0 
ff80080ec158
[2.898520] b1e0: ffc9768ab230 ff8008496d04 ffc975ce6d80 
ffc9768ab36e
[2.898527] b200: ffc9768ab36f ffc9768ab29d ffc9768ab29e 
ffc9768a
[2.898533] b220: ffc9768ab250 ff80080e70c0 ffc9768ab270 
ff8008496e44
[2.898540] b240: 01ac ffc97624c010 0010 
0010
[2.898546] b260:   01ac 

[2.898552] b280:   fb00 

[2.898558] b2a0: ffc9768a0080 00e31b70 0001 
0001
[2.898566] [] __memcpy+0x7c/0x180
[2.898574] [] nv04_fbcon_imageblit+0x1d4/0x2e8
[2.898582] [] nouveau_fbcon_imageblit+0xd8/0xe0
[2.898591] [] soft_cursor+0x154/0x1d8
[2.898598] [] bit_cursor+0x4fc/0x538
[2.898605] [] fbcon_cursor+0x134/0x1a8
[2.898613] [] hide_cursor+0x38/0xa0
[2.898620] [] redraw_screen+0x120/0x228
[2.898628] [] fbcon_prepare_logo+0x370/0x3f8
[2.898635] [] fbcon_init+0x350/0x560
[2.898641] [] visual_init+0xac/0x108
[2.898648] [] do_bind_con_driver+0x1c4/0x3a8
[2.898655] [] do_take_over_console+0x174/0x1e8
[2.898662] [] do_fbcon_takeover+0x74/0x100
[2.898669] [] fbcon_event_notify+0x8cc/0x920
[2.898680] [] notifier_call_chain+0x50/0x90
[2.898685] [] __blocking_notifier_call_chain+0x4c/0x90
[2.898691] [] blocking_notifier_call_chain+0x14/0x20
[2.898696] [] fb_notifier_call_chain+0x1c/0x28
[2.898703] [] register_framebuffer+0x1cc/0x2e0
[2.898712] [] drm_fb_helper_initial_config+0x288/0x3e8
[2.898719] [] nouveau_fbcon_init+0xe0/0x118
[2.898727] [] nouveau_drm_load+0x268/0x890
[2.898734] [] drm_dev_register+0xbc/0xc8
[2.898740] [] drm_get_pci_dev+0xa0/0x180
[2.898747] [] nouveau_drm_probe+0x1a0/0x1e0
[2.898755] [] pci_device_probe+0x98/0x110
[2.898763] [] driver_probe_device+0x204/0x2b0
[2.898770] [] __driver_attach+0xac/0xb0
[2.898777] [] bus_for_each_dev+0x60/0xa0
[2.898783] [] driver_attach+0x20/0x28
[2.898789] [] bus_add_driver+0x1d0/0x238
[2.898796] [] driver_register+0x60/0xf8
[2.898802] [] __pci_register_driver+0x3c/0x48
[2.898809] [] drm_pci_init+0xf4/0x120
[2.898818] [] nouveau_drm_init+0x21c/0x230
[2.898825] [] do_one_initcall+0x8c/0x190
[

[Nouveau] [Bug 96355] Performance: extra SSBO validation even when SSBO aren't used

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96355

--- Comment #13 from Karol Herbst  ---
(In reply to Gediminas Jakutis from comment #8)
> I don't know about the reporter's case, but I have ran some benchmarks and
> tests with f018456901ee291181ecce74c30b19c9f6731f06 (latest revision before
> those four patches) and fd6bbc2ee205ed02f66a8d8ef5b2adf4005d588c (the latest
> revision, with the four patches) on my GTX 770 + FX-8320 @ 4.1GHz, focusing
> on CPU-bound cases.
> 
> The results are all to the better - on most games I tested I see 4-10%
> performance boost. Am only going to list a pair of highlights:
> 
> · Age of Wonders III, my own severely CPU limited testcase: 21 fps -> 26
> fps, a jump by a whooping 23.8% (still CPU-bound, though).
> · Payday 2, well, this game has no [reproducable] way to benchmark it, but
> the gameplay used to be nightmare filled with severe rubber-banding, running
> just some 18-22 fps in many situations, all while painfully CPU-bound. Now,
> most of rubber-banding is either gone or is a lot less noticeable. The
> framerate in these aforementioned situations went up to 25-60; dipping below
> 30 very rarely, while mostly maintaining over 2x performance boost.
> Basically, these four patches made the game *playable* on nouveau. (The game
> is still very painfully CPU-bound, though.)
> 
> So, at least here, I can see clear performance benefits.
> Will leave to be marked as RESOLVED by the reporter; don't want to hijack
> his issue.

I saw the same thing with PAYDAY 2, but I couldn't restore the low perf so I
guess they just reworked their engine while they added the SMAA and SSAO thing,
so I doubt those patches had anything to do with that :/

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 94990] Latest 4.6rc4 kernel, no booting on gtx970

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=94990

--- Comment #29 from Andrei Dziahel  ---
Hi,

Ok, so it seems I'm affected too: my desktop with GTX970 doesn't boot kernel
4.6 (comes with recent openSUSE Tumbleweed snapshot release). Although it does
boot 4.5.4 kernel, from which I'm writing this comment.

I've found this issue by googling "timeout at
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/base.c:145" message from my logs.

Relevant log parts are pretty much identical for me, I can post them here, if
needed. 

Firmware checksums are identical. Haven't tried NvForcePost=1 and pci_msi=off
yet, will try later if needed.

Anyway, +1 here.

Motherboard: Gigabyte GA-MA770
Videocard: GTX 970 by MSI
UEFI and SecureBoot are enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 96355] Performance: extra SSBO validation even when SSBO aren't used

2016-06-06 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=96355

gregory.hain...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from gregory.hain...@gmail.com ---
Actually what I saw is that all UBOs are validated when programs are switched.
But I guess it is normal. I need to dig further. Thanks for the fixes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v2] Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

2016-06-06 Thread Alexandre Courbot 
From: Robin Murphy 

This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50.

There is apparently something amiss with the way the TTM code handles
DMA buffers, which the above commit was attempting to work around for
arm64 systems with non-coherent PCI. Unfortunately, this completely
breaks systems *with* coherent PCI (which appear to be the majority).

Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
a machine with a PCI GPU having coherent dma_map_ops (in this case a
7600GT card plugged into an ARM Juno board) results in a fatal crash:

[2.803438] nouveau :06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo 
ffc976141c00
[2.897662] Unable to handle kernel NULL pointer dereference at virtual 
address 01ac
[2.897666] pgd = ff8008e0
[2.897675] [01ac] *pgd=0009e003, *pud=0009e003, 
*pmd=
[2.897680] Internal error: Oops: 9645 [#1] PREEMPT SMP
[2.897685] Modules linked in:
[2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
[2.897694] Hardware name: ARM Juno development board (r1) (DT)
[2.897699] task: ffc9768a ti: ffc9768a8000 task.ti: 
ffc9768a8000
[2.897711] PC is at __memcpy+0x7c/0x180
[2.897719] LR is at OUT_RINGp+0x34/0x70
[2.897724] pc : [] lr : [] pstate: 
8045
[2.897726] sp : ffc9768ab360
[2.897732] x29: ffc9768ab360 x28: 0001
[2.897738] x27: ffc97624c000 x26: 
[2.897744] x25: 0080 x24: 6c00
[2.897749] x23: 0005 x22: ffc97624c010
[2.897755] x21: 0004 x20: 0004
[2.897761] x19: ffc9763da000 x18: ffc976b2491c
[2.897766] x17: 0007 x16: 0006
[2.897771] x15: 0001 x14: 0001
[2.89] x13: 00e31b70 x12: ffc9768a0080
[2.897783] x11:  x10: fb00
[2.897788] x9 :  x8 : 
[2.897793] x7 :  x6 : 01ac
[2.897799] x5 :  x4 : 
[2.897804] x3 : 0010 x2 : 0010
[2.897810] x1 : ffc97624c010 x0 : 01ac
...
[2.898494] Call trace:
[2.898499] Exception stack(0xffc9768ab1a0 to 0xffc9768ab2c0)
[2.898506] b1a0: ffc9763da000 0004 ffc9768ab360 
ff80083465fc
[2.898513] b1c0: ffc976801e00 ffc9762b8000 ffc9768ab1f0 
ff80080ec158
[2.898520] b1e0: ffc9768ab230 ff8008496d04 ffc975ce6d80 
ffc9768ab36e
[2.898527] b200: ffc9768ab36f ffc9768ab29d ffc9768ab29e 
ffc9768a
[2.898533] b220: ffc9768ab250 ff80080e70c0 ffc9768ab270 
ff8008496e44
[2.898540] b240: 01ac ffc97624c010 0010 
0010
[2.898546] b260:   01ac 

[2.898552] b280:   fb00 

[2.898558] b2a0: ffc9768a0080 00e31b70 0001 
0001
[2.898566] [] __memcpy+0x7c/0x180
[2.898574] [] nv04_fbcon_imageblit+0x1d4/0x2e8
[2.898582] [] nouveau_fbcon_imageblit+0xd8/0xe0
[2.898591] [] soft_cursor+0x154/0x1d8
[2.898598] [] bit_cursor+0x4fc/0x538
[2.898605] [] fbcon_cursor+0x134/0x1a8
[2.898613] [] hide_cursor+0x38/0xa0
[2.898620] [] redraw_screen+0x120/0x228
[2.898628] [] fbcon_prepare_logo+0x370/0x3f8
[2.898635] [] fbcon_init+0x350/0x560
[2.898641] [] visual_init+0xac/0x108
[2.898648] [] do_bind_con_driver+0x1c4/0x3a8
[2.898655] [] do_take_over_console+0x174/0x1e8
[2.898662] [] do_fbcon_takeover+0x74/0x100
[2.898669] [] fbcon_event_notify+0x8cc/0x920
[2.898680] [] notifier_call_chain+0x50/0x90
[2.898685] [] __blocking_notifier_call_chain+0x4c/0x90
[2.898691] [] blocking_notifier_call_chain+0x14/0x20
[2.898696] [] fb_notifier_call_chain+0x1c/0x28
[2.898703] [] register_framebuffer+0x1cc/0x2e0
[2.898712] [] drm_fb_helper_initial_config+0x288/0x3e8
[2.898719] [] nouveau_fbcon_init+0xe0/0x118
[2.898727] [] nouveau_drm_load+0x268/0x890
[2.898734] [] drm_dev_register+0xbc/0xc8
[2.898740] [] drm_get_pci_dev+0xa0/0x180
[2.898747] [] nouveau_drm_probe+0x1a0/0x1e0
[2.898755] [] pci_device_probe+0x98/0x110
[2.898763] [] driver_probe_device+0x204/0x2b0
[2.898770] [] __driver_attach+0xac/0xb0
[2.898777] [] bus_for_each_dev+0x60/0xa0
[2.898783] [] driver_attach+0x20/0x28
[2.898789] [] bus_add_driver+0x1d0/0x238
[2.898796] [] driver_register+0x60/0xf8
[2.898802] [] __pci_register_driver+0x3c/0x48
[2.898809] [] drm_pci_init+0xf4/0x120
[2.898818] [] nouveau_drm_init+0x21c/0x230
[2.898825] [] do_one_initcall+0x8c/0x190
[2.898832] [] kernel_init_freeable+0x14c/0x1f0
[

Re: [Nouveau] [RFC v3 10/45] cris: dma-mapping: Use unsigned long for dma_attrs

2016-06-06 Thread Jesper Nilsson 
On Thu, Jun 02, 2016 at 05:39:12PM +0200, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.

Acked-by: Jesper Nilsson 

> Signed-off-by: Krzysztof Kozlowski 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC v3 01/45] powerpc: dma-mapping: Don't hard-code the value of DMA_ATTR_WEAK_ORDERING

2016-06-06 Thread Krzysztof Kozlowski 
On 06/02/2016 05:39 PM, Krzysztof Kozlowski wrote:
> Hard-coded value of DMA_ATTR_WEAK_ORDERING is then compared with the
> symbol.  This will stop matching if the value of symbol is changed (when
> switching DMA attributes to unsigned long).
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/powerpc/platforms/cell/iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/cell/iommu.c 
> b/arch/powerpc/platforms/cell/iommu.c
> index 14a582b21274..0c2794d2b6c0 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -1162,7 +1162,7 @@ static int __init setup_iommu_fixed(char *str)
>   pciep = of_find_node_by_type(NULL, "pcie-endpoint");
>  
>   if (strcmp(str, "weak") == 0 || (pciep && strcmp(str, "strong") != 0))
> - iommu_fixed_is_weak = 1;
> + iommu_fixed_is_weak = DMA_ATTR_WEAK_ORDERING;

After some more thoughts given to this, I think my fix is not correct.
The 'iommu_fixed_is_weak' stores the bool and it is used to compare with
result of test_bit().

Please ignore this patch.

Best regards,
Krzysztof
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC v3 02/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-06 Thread Krzysztof Kozlowski 
On 06/03/2016 09:17 AM, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
>  wrote:
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -5,13 +5,25 @@
> 
>> +/**
>> + * List of possible attributes associated with a DMA mapping. The semantics
>> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
>> + */
>> +#define DMA_ATTR_WRITE_BARRIER (1UL << 1)
> 
> Any particular reason they start at 2, not 1?

No reason. I'll fix this in next version (and trim Cc-list). Anyway the
values of constants won't match old ones but that should not be problem
(unless they are hard-coded somewhere).

Best regards,
Krzysztof


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau