| Message ID | 20170329002720.11445-4-raof@ubuntu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 29/03/17 09:27 AM, raof@ubuntu.com wrote: > From: Christopher James Halse Rogers <christopher.halse.rogers@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@canonical.com> > CC: amd-gfx@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); >
On Wed, 29 Mar 2017 at 13:04 Michel Dänzer <michel@daenzer.net> wrote: > On 29/03/17 09:27 AM, raof@ubuntu.com wrote: > > From: Christopher James Halse Rogers < > christopher.halse.rogers@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@canonical.com> > > CC: amd-gfx@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. > As far as I can tell amdgpu unconditionally migrates to VRAM when trying to scanout at the moment. When that changes, so can this check :). > > + 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. > > Ta. v2 incoming.
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 */ + if (obj->import_attach) { + dev_err(&dev->pdev->dev, "Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL); if (amdgpu_fb == NULL) { drm_gem_object_unreference_unlocked(obj);