On 09/19/2018 06:38 AM, Gerd Hoffmann wrote: >>>> Once display manger is kicked off for example (sudo systemctl start lightdm.service) and >>>> resource id 3 gets created from user space down, it still gives a blank black screen. >>> >>> Hmm. I'd suspect there is simply a code path missing. Can you send the >>> patch you have? >>> >>> cheers, >>> Gerd >>> >> >> I sent the patch. For now it does dma_sync_sg on the pages in >> TRANSFER_TO_HOST_2D/3D when use_dma_api is true. >> >> https://lore.kernel.org/lkml/20180919070931.91168-1-jiandi.an@xxxxxxx/ > > Hmm, the way it is hooked up it should not miss any resource update. > So not sure why it isn't working. > Pushed the patch nevertheless as it is clearly a step into the right > direction. > > cheers, > Gerd > I did more tracing and digging. The ttm-pages that needs to be dma_synced are inside virtio_gpu_object. There are 4 VIRTIO_GPU_CMD_RESOURCE_CREATE_2D/_ATTACH_BACKING coming down the driver creating virtio_gpu_objects with resource_id = 1, 2, 3, 4 respectively. resource_id = 1 is created during driver load in the path of virtio_gpu_probe() virtio_gpu_fbdev_init() virtio_gpufb_create() In this path virtio_gpu_framebuffer_init() is called where it ties virtio_gpu_object -> drm_gem_object into virtio_gpu_framebuffer -> drm_framebuffer -> drm_gem_object obj[0] So later with given drm_gem_object, gem_to_virtio_gpu_obj() can get to the virtio_gpu_object that contains it. When kicking off display manager such as lightdm resource_id = 2, 3, and 4 are created in the drm_mode_create_dumb ioctl path drm_mode_create_dumb() drm_ioctl() drm_mode_create_dumb_ioctl() virtio_gpu_mode_dumb_create() In this path a different virtio_gpu_object is created for each resource_id. The virtio_gpu_object or the underlying drm_gem_object is not tied to virtio_gpu_framebuffer. It is published to userspace through drm_file which registers the gem_handle for the drm_gem_object. After display manger is kicked off, the VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D command is acting on the virtio_gpu_object resource created for resource_id = 3. In virtio_gpu_cmd_transfer_to_host(), it only has access to struct virtio_gpu_device, so the virtio_gpu_object it accesses through virtio_gpu_device is resource_id = 1's virtio_gpu_object. void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev, uint32_t resource_id, uint64_t offset, ... struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev; struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb; struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]); In struct drm_framebuffer, there is struct drm_gem_object *obj[4], only first element is being used here. Can the virtio_gpu_object created from user space for resource_id 3 be saved here to tie it to virtio_gpu_framebuffer? Is there better way to get to the virtio_gpu_object created in the virtio_gpu_mode_dumb_create() path from virtio_gpu_device or somehow from drm_file via gem_handle down at the layer of virtio_gpu_cmd_transfer_to_host()? Thanks - Jiandi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
