Thank you Pawel for the error message.

That seems indeed the problem, we fail in the kernel in rockchip_gem_prime_import_sg_table and then we end up returning a nullptr in minigbm and Chrome:
drv: DRM_IOCTL_PRIME_FD_TO_HANDLE failed (fd=95)
[17114:17164:0828/200952.584891:ERROR:gbm_buffer.cc(286)] nullptr returned from gbm_bo_import


Tomasz, is it possible this is an issue with the 3.14 kernel? rockchip_gem_prime_import_sg_table changed significantly from 3.14 to 4.4.

We don't really need the BO in this case, since we won't use HW overlays on minnie or on any board with a kernel < 4.4.
Should we just make sure Chrome will continue if a BO can't be imported when importing fds? We always assumed that if minigbm claimed to support a buffer format/usage, gbm_bo_import would succeed, but addFramebuffer2 might fail.

Should we allow gbm_bo_import to fail too or is it worth our time to investigate why DRM_IOCTL_PRIME_FD_TO_HANDLE is failing for NV12 on 3.14?

NV12 buffers coming via exo seem to be gbm_bo_imported fine though.

The only difference seems to be that we allocate them explicitly with gbm_bo_create and not via v4l2 interface.

The parameters we pass to gbm_bo_import seem to be the same.

Tomasz said he might have time to take a look at the issue kernel side.
Please assign it back to me in case it takes longer than expected to fix. 

Here's the fix: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/640434

That's great. Thank you Tomasz!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9481de027b6b7b643e7df19642d9da70f642f3af

commit 9481de027b6b7b643e7df19642d9da70f642f3af
Author: Tomasz Figa <tfiga@chromium.org>
Date: Wed Aug 30 02:37:08 2017

CHROMIUM: drm/rockchip: Do not call dma_buf_sg() twice on PRIME import path

Current implementation of Rockchip DRM's .gem_prime_import_sg_table()
callback calls dma_buf_sg(). However, drm_gem_prime_import() helper
already calls dma_buf_map_attachment(), which calls into exporter's
mapping code that is expected to map the buffer for the importer and
return the mapped sg_table. Calling dma_map_sg() on an already mapped
sg_table is an error and leads to failures.

Fix it by removing the redundant calls and respective calls to
dma_unmap_sg().

BUG= chromium:759408 
TEST=Open crosvideo.appspot.com on veyron_minnie, load VP8 DASH 30 FPS
  stream and make sure the whole video tag is visible to trigger the
  import.

Change-Id: I05ca2b8cccdb32778fe0715b1ab980d2699b8595
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/640434
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>

[modify] https://crrev.com/9481de027b6b7b643e7df19642d9da70f642f3af/drivers/gpu/drm/rockchip/rockchip_drm_gem.c

FYI, the same issue is present in 4.4, but affected code path is only used when IOMMU is disabled, but it actually does not make sense to import an sg_table without IOMMU (unless it's pointing to a contiguous chunk of memory), so maybe it would just make more sense to completely remove external import in this case? (Should be a separate bug if we decide to do so.)

Issue 761345 has been merged into this issue.