Problem importing buffer allocated by etnaviv to imx-drm

[Martin Fuzzey]

Hi all,

finally got back to looking at this issue.
I have now updated to
     * Android 8.1,
     * mesa 18.1.1,
     * libdrm 2.4.92
     * gbm_gralloc from git://github.com/robherring/ 
ed2c246bfc6c4bd8f9ef72b6a771814cf493c1f8
     * drm_hwc from git://anongit.freedesktop.org/git/ 
78c9f6c26210423926ea027edfab0b9504c2d7ff

The good news is that no hacks are needed to make all this build on 
Android 8 (before I was on 5.1 which only supports HWC 1 which meant 
reverting some commits).

However I'm still getting the same issue
     01-02 03:07:26.233   181   181 E hwc-platform-drm-generic: failed 
to import prime fd 13 to 6 ret=-1

(I added the destination fd log) For the same reason (non contiguous)

pkn_arm32_generic:/ # ls -l /proc/181/fd
total 0
lr-x------ 1 system graphics 64 1970-01-02 03:07 13 -> anon_inode:dmabuf
lrwx------ 1 system graphics 64 1970-01-02 03:07 6 -> /dev/dri/card1


On the i.MX6 /dev/dri/card1 is the IPU (imx-drm) and /dev/dri/card0 is 
the GPU (etnaviv)

Looking at the code in etna_resource_alloc() it seems that the 
allocation is done from imx-drm for the case of scanout buffers but from 
etnaviv for other buffers.

The fds are opened in several places:
     gbm_gralloc: gbm_dev_create()
         property_get("gralloc.gbm.device", path, "/dev/dri/renderD128")

     imx_drm_screen_create() has two fds:
         .gpu_fd hardcoded as /dev/dri/renderD128
         .kms_fd passed as parameter and used by 
renderonly_create_kms_dumb_buffer_for_resource
      This comes from the gbm_gralloc FD above

     droid_open_device() uses fd obtained from gralloc via 
GRALLOC_MODULE_PERFORM_GET_DRM_FD

     drm_hwc uses property_get("hwc.drm.device", path, "/dev/dri/card0")


With all the defaults Initially the allocation of the scanout buffer in 
renderonly_scanout_for_resource() failed because it was being done on 
the GPU render node.
Setting both gralloc.gbm.device and hwc.drm.device to /dev/dri/card1 
fixes that.

I also tried leaving the gbm_gralloc allocation parameter alone and 
modifying imx_drm_screen_create() to use /dev/dri/card1 for .kms_fd with 
the same result.

--- a/src/gallium/winsys/imx/drm/imx_drm_winsys.c
+++ b/src/gallium/winsys/imx/drm/imx_drm_winsys.c
  struct pipe_screen *imx_drm_screen_create(int fd)
  {
     struct renderonly ro = {
        .create_for_resource = 
renderonly_create_kms_dumb_buffer_for_resource,
-      .kms_fd = fd,
+      //.kms_fd = fd,
+      .kms_fd = open("/dev/dri/card1", O_RDWR | O_CLOEXEC), // MF Hack
        .gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
     };


There were also another 2 problems that I have worked around for the moment:

PrimeHandleToFD failing on the kernel side due to no authentication.
This is because, in android 8, the components have been biderized so 
there are now 4 processes involved:

1) android.hardware.graphics.allocator at 2.0-service (Allocator hosts gralloc)
2) android.hardware.graphics.composer at 2.1-service         (hosts drm_hwc)
3) surfaceflinger
4) bootanimation

Whereas in previous android versions the first 3 were all in the 
surfaceflinger process.
For the moment I have hacked around that with this on the kernel side

--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -218,6 +218,14 @@ static int drm_open_helper(struct file *filp, 
struct drm_minor *minor)

         /* for compatibility root is always authenticated */
         priv->authenticated = capable(CAP_SYS_ADMIN);
+#if 1
+       if (!priv->authenticated) {
+               dev_warn(dev->dev,
+                       "@MF@ forcing authentication BIG SECURITY HOLE 
pid=%d comm=%s\n",
+                       current->pid, current->comm);
+               priv->authenticated = 1; // MF big security hole
+       }
+#endif
         priv->lock_count = 0;


A mismatch between the versions of struct gralloc_handle_t used by 
gbm_gralloc and drm_hwc
gbm_gralloc uses  external/gbm_gralloc/gralloc_drm_handle.h
whereas drm_hwc uses external/libdrm/android/gralloc_handle.h

This caused the format code to be misinterpreted leading to
      01-02 00:35:01.242   181   181 E hwc-platform-drm-generic: Cannot 
convert hal format to drm format 2304


Regards

Martin