Problem importing buffer allocated by etnaviv to imx-drm

[Robert Foss]

Hey Martin (& Chris),

On 2018-07-11 19:14, Martin Fuzzey wrote:
> 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.

This has been a re-occuring pain point on devices with multiple DRM nodes to 
chose from, but recently I added node probing support to mesa which lets you 
avoid hardcoded paths.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=c7bb82136b48b99427465ba4fa3ce477cf09e097

> 
> 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
> 

Rob Herrings has mentioned that pushing a dev branch for the gbm_gralloc handle 
support is on his Todo list.
But for now there is another branch, which reportedly has been working better.

https://github.com/robherring/gbm_gralloc/commits/handle-rework-v2

> 
> Regards
> 
> Martin
> 
>