[Nouveau] [Bug 71900] [NV40] GPU lockup and segmentation fault of Nouveau-1.0.10 on PowerMac G5 with acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=71900 --- Comment #12 from Alex Perez --- Ping, this bug is zombified. It's been open for nearly five years now, and hasn't had a comment in over two years. Ben, two years ago, you wrote "I plan on attempting to untangle the vm mess in the next few weeks, and this will be one of the things I'll attempt to address while doing so." Did anything ever come of that? -- 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 71900] [NV40] GPU lockup and segmentation fault of Nouveau-1.0.10 on PowerMac G5 with acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=71900 --- Comment #13 from Ilia Mirkin --- Alex, which issue are you talking about? Like almost every issue where someone says "me too", they actually have a totally different issue. Here's a list of problems: - MSI is broken - 64k pages are broken - Undiagnosed issue with the NV40 AGP AFAIK all these issues are wholly unrelated to each other. -- 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 00/29] DRM API conversions
This patch set replaces the occurrences of drm_*_reference() and
drm_*_unreference() with the new drm_*_get() and drm_*_put() functions.
All patches in the series do the same thing, converting to the new APIs.
I created patches per DRM driver as suggested by Daniel Vetter.
Background:
In the kernel, reference counting APIs use *_get(), *_put() style naming
to reference-count the objects. But DRM subsystem uses a different
naming for them such as *_reference(), *_unreference() which is
inconsistent with the other reference counting APIs in the kernel. To
solve this consistency issue, Thierry Reding introduced a couple of
functions and compatibility aliases in the following commits for them.
commit 020a218f95bd3ceff7dd1022ff7ebc0497bc7bf9
Author: Thierry Reding
Date: Tue Feb 28 15:46:38 2017 +0100
drm: Introduce drm_mode_object_{get,put}()
commit ad09360750afa18a0a0ce0253d6ea6033abc22e7
Author: Thierry Reding
Date: Tue Feb 28 15:46:39 2017 +0100
drm: Introduce drm_connector_{get,put}()
commit a4a69da06bc11a937a6e417938b1bb698ee1fa46
Author: Thierry Reding
Date: Tue Feb 28 15:46:40 2017 +0100
drm: Introduce drm_framebuffer_{get,put}()
commit e6b62714e87c8811d5564b6a0738dcde63a51774
Author: Thierry Reding
Date: Tue Feb 28 15:46:41 2017 +0100
drm: Introduce drm_gem_object_{get,put}()
commit 6472e5090be7c78749a3c279b4faae87ab835c40
Author: Thierry Reding
Date: Tue Feb 28 15:46:42 2017 +0100
drm: Introduce drm_property_blob_{get,put}()
This patch set was generated using the following shell script:
#!/bin/sh
path=$1
do_replace() {
local pattern=$1
local replacement=$2
git grep -lw "${pattern}" -- "${path}/*.[hc]" |\
xargs -r sed -i "s/\b$pattern\b/$replacement/g"
}
do_replace drm_mode_object_reference drm_mode_object_get
do_replace drm_mode_object_unreference drm_mode_object_put
do_replace drm_connector_reference drm_connector_get
do_replace drm_connector_unreference drm_connector_put
do_replace drm_framebuffer_reference drm_framebuffer_get
do_replace drm_framebuffer_unreference drm_framebuffer_put
do_replace drm_gem_object_reference drm_gem_object_get
do_replace drm_gem_object_unreference drm_gem_object_put
do_replace __drm_gem_object_unreference __drm_gem_object_put
do_replace drm_gem_object_unreference_unlocked drm_gem_object_put_unlocked
do_replace drm_property_reference_blob drm_property_blob_get
do_replace drm_property_unreference_blob drm_property_blob_put
Cihangir Akturk (29):
drm/amdgpu: switch to drm_*{get,put} helpers
drm: mali-dp: switch to drm_*{get,put} helpers
drm/armada: switch to drm_*{get,put} helpers
drm/ast: switch to drm_*{get,put} helpers
drm/atmel-hlcdc: switch to drm_*{get,put} helpers
drm/bochs: switch to drm_*{get,put} helpers
drm/cirrus: switch to drm_*{get,put} helpers
drm/etnaviv: switch to drm_*{get,put} helpers
drm/exynos: switch to drm_*{get,put} helpers
drm/gma500: switch to drm_*{get,put} helpers
drm/hisilicon: switch to drm_*{get,put} helpers
drm/i915: switch to drm_*{get,put} helpers
drm/imx: switch to drm_*{get,put} helpers
drm/mediatek: switch to drm_*{get,put} helpers
drm/mgag200: switch to drm_*{get,put} helpers
drm/msm: switch to drm_*{get,put} helpers
drm/nouveau: switch to drm_*{get,put} helpers
drm/omap: switch to drm_*{get,put} helpers
drm/qxl: switch to drm_*{get,put} helpers
drm/radeon: switch to drm_*{get,put} helpers
drm/rockchip: switch to drm_*{get,put} helpers
drm/tegra: switch to drm_*{get,put} helpers
drm/tilcdc: switch to drm_*{get,put} helpers
drm/udl: switch to drm_*{get,put} helpers
drm/vc4: switch to drm_*{get,put} helpers
drm/vgem: switch to drm_*{get,put} helpers
drm/virtio: switch to drm_*{get,put} helpers
drm/vmwgfx: switch to drm_*{get,put} helpers
staging: vboxvideo: switch to drm_*{get,put} helpers
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 22 -
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 6 ++---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 6 ++---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++---
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c | 22 -
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/armada/armada_fb.c| 8 +++---
drivers/gpu/drm/armada/armada_fbdev.c | 6 ++---
drivers/gpu/drm/armada/armada_gem.c | 14 +--
drivers/gpu/drm/armada/armada_overlay.c | 4 +--
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/ast/ast_main.c| 10
drivers/g
Re: [Nouveau] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property
On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_cursor.c| 1 - > drivers/gpu/drm/sti/sti_gdp.c | 1 - > drivers/gpu/drm/sti/sti_hqvdp.c | 1 - Acked-by: Vincent Abriou BR Vincent ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property
Hi Daniel, Thank you for the patch. On Tuesday 25 Jul 2017 10:01:19 Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. I assume you meant drm_atomic_plane_set_property. With that fixed, Reviewed-by: Laurent Pinchart > Signed-off-by: Daniel Vetter > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: Mali DP Maintainers > Cc: Boris Brezillon > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: Sean Paul > Cc: David Airlie > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Laurent Pinchart > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Jyri Sarha > Cc: "Ville Syrjälä" > Cc: Rongrong Zou > Cc: Shawn Guo > Cc: Alexey Brodkin > Cc: Eric Engestrom > Cc: Chris Wilson > Cc: Rob Clark > Cc: Archit Taneja > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: nouveau@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: Thomas Hellstrom > Cc: Maxime Ripard > --- > drivers/gpu/drm/arm/malidp_planes.c | 1 - > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 1 - > drivers/gpu/drm/drm_atomic.c| 3 +- > drivers/gpu/drm/drm_atomic_helper.c | 55 -- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 - > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 1 - > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 - > drivers/gpu/drm/i915/intel_display.c| 2 - > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 - > drivers/gpu/drm/nouveau/nv50_display.c | 1 - > drivers/gpu/drm/omapdrm/omap_plane.c| 1 - > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 - > drivers/gpu/drm/sti/sti_cursor.c| 1 - > drivers/gpu/drm/sti/sti_gdp.c | 1 - > drivers/gpu/drm/sti/sti_hqvdp.c | 1 - > drivers/gpu/drm/stm/ltdc.c | 1 - > drivers/gpu/drm/tilcdc/tilcdc_plane.c | 1 - > include/drm/drm_atomic.h| 3 -- > include/drm/drm_atomic_helper.h | 3 -- > 20 files changed, 1 insertion(+), 81 deletions(-) -- Regards, Laurent Pinchart ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] drm/etnaviv: add thermal dependency
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':
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to
> `thermal_of_cooling_device_register'
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0xe0): undefined reference to
> `thermal_cooling_device_unregister'
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_unbind+0xf0): undefined reference to
> `thermal_cooling_device_unregister'
>
> This adds a Kconfig dependency to prevent etnaviv from being built-in
> with CONFIG_THERMAL=m, while still allowing the valid configurations.
> Unfortunately, simply adding the dependency here breaks Kconfig through
> a dependency loop involving lots of symbols all the way until ACPI_VIDEO,
> which is the only video driver that explicitly selects 'THERMAL'. Turning
> this into a 'depends on' addresses the problem.
> For completeness, I'm also removing the redundant 'select THERMAL'
> from INTEL_MENLOW, so no other driver uses that statement.
>
> Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
> Signed-off-by: Arnd Bergmann
> ---
> v2: spend more thought on ACPI_VIDEO dependencies, as we need another
> patch before this.
> ---
> drivers/acpi/Kconfig| 2 +-
> drivers/gpu/drm/etnaviv/Kconfig | 1 +
> drivers/platform/x86/Kconfig| 1 -
I would like to take this patch, but I'm not sure why it includes x86
and ACPI hunks.
Regards,
Lucas
> 3 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index a8f5a40e2914..1282b2936164 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -184,7 +184,7 @@ config ACPI_VIDEO
> tristate "Video"
> depends on X86
> depends on INPUT
> - select THERMAL
> + depends on THERMAL
> select BACKLIGHT_CLASS_DEVICE
> select BACKLIGHT_LCD_SUPPORT
> default y
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 71cee4e9fefb..1d6c744e7924 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -3,6 +3,7 @@ config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
> + depends on THERMAL || THERMAL=n
> depends on MMU
> select SHMEM
> select SYNC_FILE
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 2d9fb46a8d11..d9238e9ff54a 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -532,7 +532,6 @@ config SENSORS_HDAPS
> config INTEL_MENLOW
> tristate "Thermal Management driver for Intel menlow platform"
> depends on ACPI_THERMAL
> - select THERMAL
> ---help---
> ACPI thermal management enhancement driver on
> Intel Menlow platform.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms
On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2: Rebase over the panel/brideg refactorings in stm/ltdc. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_dvo.c | 1 - > drivers/gpu/drm/sti/sti_hda.c | 1 - > drivers/gpu/drm/sti/sti_hdmi.c | 1 - Acked-by: Vincent Abriou BR Vincent ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
On 9 August 2017 at 09:42, Joe Kniss wrote: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle() function pointer from drm_framebuffer_funcs. The > corresponding *_create_handle() function is removed from each driver. > > In many cases this change eliminates a struct *_framebuffer object, > as the only need for the derived struct is the addition of the gem > object pointer. Why the libdrm in the tag? this isn't for libdrm. This will break drivers that don't current implement the virtual at all. I think vwmgfx. The current code checks if the virtual is there before callng it, this code just calls the gem code always. Dave. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 17/29] drm/nouveau: switch to drm_*{get, put} helpers
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() adn should not be
used by new code. So convert all users of compatibility functions to use
the new APIs.
Signed-off-by: Cihangir Akturk
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 8
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++---
drivers/gpu/drm/nouveau/nv50_display.c| 2 +-
6 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 4b4b0b4..18b4be1 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1019,7 +1019,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
- drm_gem_object_unreference_unlocked(gem);
+ drm_gem_object_put_unlocked(gem);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index f98f800..3e9db5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -136,7 +136,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
if (chan->ntfy) {
nouveau_bo_vma_del(chan->ntfy, &chan->ntfy_vma);
nouveau_bo_unpin(chan->ntfy);
- drm_gem_object_unreference_unlocked(&chan->ntfy->gem);
+ drm_gem_object_put_unlocked(&chan->ntfy->gem);
}
if (chan->heap.block_size)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 8d1df56..a68fe1a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -206,7 +206,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer
*drm_fb)
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
if (fb->nvbo)
- drm_gem_object_unreference_unlocked(&fb->nvbo->gem);
+ drm_gem_object_put_unlocked(&fb->nvbo->gem);
drm_framebuffer_cleanup(drm_fb);
kfree(fb);
@@ -267,7 +267,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
if (ret == 0)
return &fb->base;
- drm_gem_object_unreference_unlocked(gem);
+ drm_gem_object_put_unlocked(gem);
return ERR_PTR(ret);
}
@@ -947,7 +947,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
return ret;
ret = drm_gem_handle_create(file_priv, &bo->gem, &args->handle);
- drm_gem_object_unreference_unlocked(&bo->gem);
+ drm_gem_object_put_unlocked(&bo->gem);
return ret;
}
@@ -962,7 +962,7 @@ nouveau_display_dumb_map_offset(struct drm_file *file_priv,
if (gem) {
struct nouveau_bo *bo = nouveau_gem_object(gem);
*poffset = drm_vma_node_offset_addr(&bo->bo.vma_node);
- drm_gem_object_unreference_unlocked(gem);
+ drm_gem_object_put_unlocked(gem);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 2665a07..6c9e1ec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -451,7 +451,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct
nouveau_fbdev *fbcon)
nouveau_bo_vma_del(nouveau_fb->nvbo, &nouveau_fb->vma);
nouveau_bo_unmap(nouveau_fb->nvbo);
nouveau_bo_unpin(nouveau_fb->nvbo);
- drm_framebuffer_unreference(&nouveau_fb->base);
+ drm_framebuffer_put(&nouveau_fb->base);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 2170534..653425c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -281,7 +281,7 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data,
}
/* drop reference from allocate - handle holds it now */
- drm_gem_object_unreference_unlocked(&nvbo->gem);
+ drm_gem_object_put_unlocked(&nvbo->gem);
return ret;
}
@@ -350,7 +350,7 @@ validate_fini_no_ticket(struct validate_op *op, struct
nouveau_fence *fence,
list_del(&nvbo->entry);
nvbo->reserved_by = NULL;
ttm_bo_unreserve_ticket(&nvbo->bo, &op->ticket);
- drm_gem_object_unreference_unlocked(&nvbo->gem);
+ drm_gem_object_put_unlocked(&nvbo->gem);
}
}
@@ -396,14 +396,14 @@ validate_init(struct nouveau_channel *chan, struct
drm_file *file_priv,
nvbo = no
Re: [Nouveau] [PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.
Hi Joe,
Thank you for the patch.
On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote:
> New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric
> with addfb2.
What's the use case for this ? We haven't needed such an ioctl for so long
that it seemed to me that userspace doesn't really need it, but I could be
wrong.
> Also modifies *_fb_create_handle() calls to accept a
> format_plane_index so that handles for each plane can be generated.
> Previously, many *_fb_create_handle() calls simply defaulted to plane 0
> only.
And with this patch the amd/amdgpu, armada, gma500, i915, mediatek, msm,
nouveau and radeon drivers still do. Do none of them support multi-planar
formats ?
> Signed-off-by: Joe Kniss
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +-
> drivers/gpu/drm/armada/armada_fb.c | 1 +
> drivers/gpu/drm/drm_crtc_internal.h | 2 +
> drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
> drivers/gpu/drm/drm_framebuffer.c | 79 +-
> drivers/gpu/drm/drm_ioctl.c | 1 +
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 7 ++-
> drivers/gpu/drm/gma500/framebuffer.c| 2 +
> drivers/gpu/drm/i915/intel_display.c| 1 +
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 1 +
> drivers/gpu/drm/msm/msm_fb.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
> drivers/gpu/drm/omapdrm/omap_fb.c | 5 +-
> drivers/gpu/drm/radeon/radeon_display.c | 5 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++-
> drivers/gpu/drm/tegra/fb.c | 9 +++-
> include/drm/drm_framebuffer.h | 1 +
> include/uapi/drm/drm.h | 2 +
> 18 files changed, 127 insertions(+), 17 deletions(-)
[snip]
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c index 28a0108a1ab8..67b3be1bedbc 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
[snip]
> +/**
> + * drm_mode_getfb2 - get FB info
> + * @dev: drm device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: drm file for the ioctl call
> + *
> + * Lookup the FB given its ID and return info about it.
> + *
> + * Called by the user via ioctl.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_getfb2(struct drm_device *dev,
> +void *data, struct drm_file *file_priv)
> +{
> + struct drm_mode_fb_cmd2 *r = data;
> + struct drm_framebuffer *fb;
> + int ret, i;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + fb = drm_framebuffer_lookup(dev, r->fb_id);
> + if (!fb)
> + return -ENOENT;
> +
> + r->height = fb->height;
> + r->width = fb->width;
> + r->pixel_format = fb->format->format;
> + for (i = 0; i < 4; ++i) {
> + r->pitches[i] = fb->pitches[i];
> + r->offsets[i] = fb->offsets[i];
> + r->modifier[i] = fb->modifier;
> + r->handles[i] = 0;
> + }
> +
> + for (i = 0; i < fb->format->num_planes; ++i) {
> + if (fb->funcs->create_handle) {
> + if (drm_is_current_master(file_priv) ||
> + capable(CAP_SYS_ADMIN) ||
> + drm_is_control_client(file_priv)) {
> + ret = fb->funcs->create_handle(fb, i,
> file_priv,
> +
> &r->handles[i]);
> + if (ret)
> + break;
> + } else {
> + /* GET_FB() is an unprivileged ioctl so we
> must
> + * not return a buffer-handle to non-master
> + * processes! For backwards-compatibility
> + * reasons, we cannot make GET_FB()
> privileged,
> + * so just return an invalid handle for
> + * non-masters. */
There's no backward compatibility to handle here, just make it privileged if
it has to be.
> + r->handles[i] = 0;
> + ret = 0;
> + }
> + } else {
> + ret = -ENODEV;
> + break;
> + }
> + }
> +
> + /* If handle creation failed, delete/dereference any that were made.
*/
> + if (ret) {
> + for (i = 0; i < 4; ++i) {
> + if (r->handles[i])
> + drm_gem_handle_delete(file_priv, r-
>handles[i]);
My initial reaction to this was to reply that not all drivers use GEM, but
after some investigation it seems they actually do. If that's really th
Re: [Nouveau] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property
On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_connector_set_property. > > The only special case is nouveau which used one function for both > pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > What is rather strange here is how few drivers set this up, I suspect > the earlier patch to handle properties in the core did end up fixing a > pile of possible issues. > > Signed-off-by: Daniel Vetter [...] > drivers/gpu/drm/sti/sti_hdmi.c | 1 - Acked-by: Vincent Abriou BR Vincent ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.
Hi Joe,
On Tuesday 01 Aug 2017 10:24:25 Joe Kniss wrote:
> On Tue, Aug 1, 2017 at 5:09 AM, Laurent Pinchart wrote:
> > On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote:
> >> New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric
> >> with addfb2.
> >
> > What's the use case for this ? We haven't needed such an ioctl for so long
> > that it seemed to me that userspace doesn't really need it, but I could be
> > wrong.
>
> Sorry, I failed to reference the original email. Here it is:
>
>
> I am a recent addition to Google's ChromeOS gfx team. I am currently
> working on display testing and reporting. An important part of this is
> our screen capture tool, which works by querying drm for crtcs, planes, and
> fbs. Unfortunately, there is only limited information available via
> drmModeGetFB(), which often wrong information when drmModeAddFB2() was used
> to create the fbs. For example, if the pixel format is NV12 or YUV420,
> the fb returned knows nothing about the additional buffer planes required
> by these formats. Ideally, we would like a function (e.g. drmModeGetFB2)
> to return information symmetric with drmModeAddFB2 including the pixel
> format id, buffer plane information etc.
>
>
> ChromeOS has needed this functionality from the start, for both testing and
> error reporting. We got away with guessing the buffer's format (32bit
> xrgb) until now. We are now enabling overlays and more formats including
> multi-planar (e.g. NV12). Current getfb() reports neither the pixel format
> nor planar information. Without this information, going forward, our gfx
> testing is going to break. It would be great if we had access to higher
> level buffer structs (like gbm), but we generally don't since they would be
> created by other apps (chrome browser, android apps, etc...).
How is screen capture implemented ? Do you enumerate the framebuffers being
scanned out, dump their contents and compose them manually based on the active
plane configuration ? If so, isn't this very race-prone ?
> >> Also modifies *_fb_create_handle() calls to accept a
> >> format_plane_index so that handles for each plane can be generated.
> >> Previously, many *_fb_create_handle() calls simply defaulted to plane 0
> >> only.
> >
> > And with this patch the amd/amdgpu, armada, gma500, i915, mediatek, msm,
> > nouveau and radeon drivers still do. Do none of them support multi-planar
> > formats ?
>
> I would imagine that some of these do support multi-planar formats, but
> they don't appear to have them implemented yet (except perhaps as offsets
> into a single buffer). I will certainly be looking into this soon, but any
> changes will come in future patches.
>
> >> Signed-off-by: Joe Kniss
> >> ---
> >>
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +-
> >> drivers/gpu/drm/armada/armada_fb.c | 1 +
> >> drivers/gpu/drm/drm_crtc_internal.h | 2 +
> >> drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
> >> drivers/gpu/drm/drm_framebuffer.c | 79 +++-
> >> drivers/gpu/drm/drm_ioctl.c | 1 +
> >> drivers/gpu/drm/exynos/exynos_drm_fb.c | 7 ++-
> >> drivers/gpu/drm/gma500/framebuffer.c| 2 +
> >> drivers/gpu/drm/i915/intel_display.c| 1 +
> >> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 1 +
> >> drivers/gpu/drm/msm/msm_fb.c| 5 +-
> >> drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
> >> drivers/gpu/drm/omapdrm/omap_fb.c | 5 +-
> >> drivers/gpu/drm/radeon/radeon_display.c | 5 +-
> >> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++-
> >> drivers/gpu/drm/tegra/fb.c | 9 +++-
> >> include/drm/drm_framebuffer.h | 1 +
> >> include/uapi/drm/drm.h | 2 +
> >> 18 files changed, 127 insertions(+), 17 deletions(-)
> >
> > [snip]
> >
> >> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> >> b/drivers/gpu/drm/drm_framebuffer.c index 28a0108a1ab8..67b3be1bedbc
> >> 100644
> >> --- a/drivers/gpu/drm/drm_framebuffer.c
> >> +++ b/drivers/gpu/drm/drm_framebuffer.c
> >> @@ -24,6 +24,7 @@
[snip]
> >> +/**
> >> + * drm_mode_getfb2 - get FB info
> >> + * @dev: drm device for the ioctl
> >> + * @data: data pointer for the ioctl
> >> + * @file_priv: drm file for the ioctl call
> >> + *
> >> + * Lookup the FB given its ID and return info about it.
> >> + *
> >> + * Called by the user via ioctl.
> >> + *
> >> + * Returns:
> >> + * Zero on success, negative errno on failure.
> >> + */
> >> +int drm_mode_getfb2(struct drm_device *dev,
> >> +void *data, struct drm_file *file_priv)
> >> +{
> >> + struct drm_mode_fb_cmd2 *r = data;
> >> + struct drm_framebuffer *fb;
> >> + int ret, i;
> >> +
> >> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> >> + return -EINVAL;
> >> +
> >> + fb = drm_framebuffer_lookup(dev, r->fb_id);
> >> + if (!fb)
> >> + return -ENOENT;
Re: [Nouveau] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Den 09.08.2017 01.42, skrev Joe Kniss:
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer object,
as the only need for the derived struct is the addition of the gem
object pointer.
TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
Signed-off-by: Joe Kniss
---
Hi Joe,
I'm also looking into adding gem objs to drm_framebuffer in this patch:
[PATCH v2 01/22] drm: Add GEM backed framebuffer library
https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
[...]
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index ade319d10e70..f5f011b910b1 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -31,14 +31,9 @@
#define DEFAULT_FBDEFIO_DELAY_MS 50
-struct drm_fb_cma {
- struct drm_framebuffer fb;
- struct drm_gem_cma_object *obj[4];
-};
-
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
- struct drm_fb_cma *fb;
+ struct drm_framebuffer *fb;
This fb pointer isn't necessary, since fb_helper already has one.
Noralf.
const struct drm_framebuffer_funcs *fb_funcs;
};
@@ -72,7 +67,6 @@ struct drm_fbdev_cma {
*
* static struct drm_framebuffer_funcs driver_fb_funcs = {
* .destroy = drm_fb_cma_destroy,
- * .create_handle = drm_fb_cma_create_handle,
* .dirty = driver_fb_dirty,
* };
*
@@ -90,67 +84,50 @@ static inline struct drm_fbdev_cma *to_fbdev_cma(struct
drm_fb_helper *helper)
return container_of(helper, struct drm_fbdev_cma, fb_helper);
}
-static inline struct drm_fb_cma *to_fb_cma(struct drm_framebuffer *fb)
-{
- return container_of(fb, struct drm_fb_cma, fb);
-}
-
void drm_fb_cma_destroy(struct drm_framebuffer *fb)
{
- struct drm_fb_cma *fb_cma = to_fb_cma(fb);
int i;
for (i = 0; i < 4; i++) {
- if (fb_cma->obj[i])
- drm_gem_object_put_unlocked(&fb_cma->obj[i]->base);
+ if (fb->gem_objs[i])
+ drm_gem_object_put_unlocked(fb->gem_objs[i]);
}
drm_framebuffer_cleanup(fb);
- kfree(fb_cma);
+ kfree(fb);
}
EXPORT_SYMBOL(drm_fb_cma_destroy);
-int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
- struct drm_file *file_priv, unsigned int *handle)
-{
- struct drm_fb_cma *fb_cma = to_fb_cma(fb);
-
- return drm_gem_handle_create(file_priv,
- &fb_cma->obj[0]->base, handle);
-}
-EXPORT_SYMBOL(drm_fb_cma_create_handle);
-
static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
.destroy= drm_fb_cma_destroy,
- .create_handle = drm_fb_cma_create_handle,
};
-static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
+static struct drm_framebuffer *drm_fb_cma_alloc(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_cma_object **obj,
unsigned int num_planes, const struct drm_framebuffer_funcs *funcs)
{
- struct drm_fb_cma *fb_cma;
+ struct drm_framebuffer *fb;
int ret;
int i;
- fb_cma = kzalloc(sizeof(*fb_cma), GFP_KERNEL);
- if (!fb_cma)
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (!fb)
return ERR_PTR(-ENOMEM);
- drm_helper_mode_fill_fb_struct(dev, &fb_cma->fb, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
for (i = 0; i < num_planes; i++)
- fb_cma->obj[i] = obj[i];
+ fb->gem_objs[i] = &obj[i]->base;
- ret = drm_framebuffer_init(dev, &fb_cma->fb, funcs);
+ ret = drm_framebuffer_init(dev, fb, funcs);
if (ret) {
dev_err(dev->dev, "Failed to initialize framebuffer: %d\n",
ret);
- kfree(fb_cma);
+ kfree(fb);
return ERR_PTR(ret);
}
- return fb_cma;
+ return fb;
}
/**
@@ -171,7 +148,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct
drm_device *dev,
const struct drm_framebuffer_funcs *funcs)
{
const struct drm_format_info *info;
- struct drm_fb_cma *fb_cma;
+ struct drm_framebuffer *fb;
struct drm_gem_cma_object *objs[4];
struct drm_gem_object *obj;
int ret;
@@ -205,13 +182,13 @@ struct drm_framebuffer
*drm_fb_cma_create_with_funcs(struct drm_device *dev,
objs[i] = to_drm_gem_cma_obj(obj);
}
- fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
- if (IS_ERR(fb_cma)) {
- ret = PTR_ERR(f
[Nouveau] [Bug 102135] New: WARN_ON hit when loading G71 with v4.13-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=102135 Bug ID: 102135 Summary: WARN_ON hit when loading G71 with v4.13-rc3 Product: xorg Version: unspecified Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: ape...@alexperez.com QA Contact: xorg-t...@lists.x.org Created attachment 133417 --> https://bugs.freedesktop.org/attachment.cgi?id=133417&action=edit dmesg on linux-4.13-rc4 ppc64 Filing at the request of Ilia Mirkin -- 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 102135] WARN_ON hit when loading G71 with v4.13-rc4
https://bugs.freedesktop.org/show_bug.cgi?id=102135 Alex Perez changed: What|Removed |Added Summary|WARN_ON hit when loading|WARN_ON hit when loading |G71 with v4.13-rc3 |G71 with v4.13-rc4 -- 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 102135] WARN_ON hit when loading G71 with v4.13-rc4
https://bugs.freedesktop.org/show_bug.cgi?id=102135 --- Comment #1 from Alex Perez --- Created attachment 133418 --> https://bugs.freedesktop.org/attachment.cgi?id=133418&action=edit attached G71 vbios from this board. -- 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 102135] WARN_ON hit when loading G71 with v4.13-rc4
https://bugs.freedesktop.org/show_bug.cgi?id=102135 --- Comment #2 from Ilia Mirkin --- The issue at hand being the multiple WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c:180 .nvkm_outp_init+0x170/0x2d0 which happen inside nvkm_disp_init. According to Alex, the board works fine (except for MSI being broken, but that's unrelated). -- 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 libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
On Wed, Aug 9, 2017 at 12:14 PM, Noralf Trønnes wrote:
>
> Den 09.08.2017 01.42, skrev Joe Kniss:
>>
>> Because all drivers currently use gem objects for framebuffer planes,
>> the virtual create_handle() is not required. This change adds a
>> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
>> create_handle() function pointer from drm_framebuffer_funcs. The
>> corresponding *_create_handle() function is removed from each driver.
>>
>> In many cases this change eliminates a struct *_framebuffer object,
>> as the only need for the derived struct is the addition of the gem
>> object pointer.
>>
>> TESTED: compiled: allyesconfig ARCH=x86,arm platforms:i915, rockchip
>>
>> Signed-off-by: Joe Kniss
>> ---
>
>
> Hi Joe,
>
> I'm also looking into adding gem objs to drm_framebuffer in this patch:
> [PATCH v2 01/22] drm: Add GEM backed framebuffer library
> https://lists.freedesktop.org/archives/dri-devel/2017-August/149782.html
>
Great. There's only minimal overlap here. I'll rebase this change on yours
once it's in.
> [...]
>
>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>> b/drivers/gpu/drm/drm_fb_cma_helper.c
>> index ade319d10e70..f5f011b910b1 100644
>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> @@ -31,14 +31,9 @@
>> #define DEFAULT_FBDEFIO_DELAY_MS 50
>> -struct drm_fb_cma {
>> - struct drm_framebuffer fb;
>> - struct drm_gem_cma_object *obj[4];
>> -};
>> -
>> struct drm_fbdev_cma {
>> struct drm_fb_helperfb_helper;
>> - struct drm_fb_cma *fb;
>> + struct drm_framebuffer *fb;
>
>
> This fb pointer isn't necessary, since fb_helper already has one.
>
I'll remove it... but I am sure when I look deeper there will be more
of these in the various drivers too.
> Noralf.
>
>
-joe
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 102106] xorg crashes when running gscan2pdf (libgtk2-perl) test case
https://bugs.freedesktop.org/show_bug.cgi?id=102106 --- Comment #4 from Ilia Mirkin --- Works for me... $ DISPLAY=:1 PERL5LIB="blib:lib:$PERL5LIB" perl t/114_cancel_save_pdf.t 1..1 test.jpg JPEG 70x46 70x46+0+0 8-bit sRGB 2649B 0.000u 0:00.000 ok 1 - can create a valid JPG after cancelling save PDF process Where DISPLAY=:1 is running on a G92 GPU. Xorg 1.19.3 + xf86-video-nouveau 1.0.15 -- 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 100423] MMIO read of 00000000 FAULT at 022554 [ IBUS ]
https://bugs.freedesktop.org/show_bug.cgi?id=100423 --- Comment #5 from ros...@gmail.com --- I've bisected the issue. It happens with this commit: fb/gf100-: modify constructors to allow more customisation -- 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 102135] WARN_ON hit when loading G71 with v4.13-rc4
https://bugs.freedesktop.org/show_bug.cgi?id=102135 --- Comment #3 from Ilia Mirkin --- Should be fixed by: https://github.com/skeggsb/nouveau/commit/33d8409a5cd51f347ab3f5b848b82b331ac7e279 -- 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
