On 29/03/17 09:27 AM, raof at ubuntu.com wrote:
> From: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com>
>
> Any use of the framebuffer will migrate it to VRAM, which is not sensible for
> an imported dma-buf.
>
> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com>
> CC: amd-gfx at lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 39fc388f222a..e7c3cc5b7d62 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -612,6 +612,12 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
> return ERR_PTR(-ENOENT);
> }
>
> + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */
Newer APUs support scanout from GTT, though they still impose some
restrictions which will probably not be satisfied in general by BOs
imported from other drivers. So this is probably okay for now.
> + if (obj->import_attach) {
> + dev_err(&dev->pdev->dev, "Cannot create framebuffer from imported dma_buf\n");
This should probably be something like DRM_DEBUG, so userspace can't
spam dmesg by default. Same for patch 5.
> + return ERR_PTR(-EINVAL);
> + }
> +
> amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
> if (amdgpu_fb == NULL) {
> drm_gem_object_unreference_unlocked(obj);
>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
