Den 04.02.2019 16.01, skrev Rob Herring:
On Sat, Feb 2, 2019 at 12:22 PM Noralf Trønnes noralf@tronnes.org wrote:
Den 02.02.2019 18.07, skrev Rob Herring:
Other than using a rockchip_gem_object directly, the Rockchip fbdev setup has nothing special and can be converted to use the generic fbdev emulation instead.
[...]
-static int rockchip_drm_fbdev_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)-{
struct rockchip_drm_private *private = to_drm_private(helper);struct drm_mode_fb_cmd2 mode_cmd = { 0 };struct drm_device *dev = helper->dev;struct rockchip_gem_object *rk_obj;struct drm_framebuffer *fb;unsigned int bytes_per_pixel;unsigned long offset;struct fb_info *fbi;size_t size;int ret;bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);mode_cmd.width = sizes->surface_width;mode_cmd.height = sizes->surface_height;mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,sizes->surface_depth);size = mode_cmd.pitches[0] * mode_cmd.height;rk_obj = rockchip_gem_create_object(dev, size, true);I don't think the generic emulation in it's current form will work for rockchip. rockchip treats fbdev buffers and dumb buffers differently. If it uses DMA buffers, then the dumb buffer can't get a virtual address.
Yes, you are right. I tested the iommu case.
From rockchip_gem_alloc_dma():
if (!alloc_kmap) rk_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;From rockchip_gem_prime_vmap():
if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) return NULL;Maybe it's possible to vmap a buffer created using dma_alloc_attrs() after the allocation?
It should be possible I think as that is what drm_gem_cma_prime_import_sg_table_vmap() does. One problem though is you may already have a mapping because DMA_ATTR_NO_KERNEL_MAPPING is just a suggestion (only 32-bit ARM implements) and there's not a way to tell if you got a mapping or not. Maybe it's not all that important if there are 2 mappings because I think only fbcon needs a kernel mapping.
My follow-up to this was going to be converting Rockchip to use CMA and the shmem helpers. So I was already wondering about what to do with DMA_ATTR_NO_KERNEL_MAPPING. There's several drivers not using CMA just to set DMA_ATTR_NO_KERNEL_MAPPING. So it would be good to come up with a solution here.
Here's part of a discussion concerning the mediatek driver (couldn't find it in the dri-devel archives):
Re: [PATCH] drm/mediatek: Add MTK Framebuffer-Device (mt7623)
On Fri, 2019-01-11 at 17:07 +0100, Noralf Trønnes wrote:
...
The problem here is that this driver doesn't map a virtual address for its buffers: mtk_gem->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
Probably because of limited virtual address space. rockchip is in the same situation.
I'm aware of this shortcoming of the generic emulation, but I don't see how it can be solved without using somekind of flag attached to the dumb buffer creation request.
The virtual address space is limited so we do not map it by default. I also see the shortcoming of the generic emulation, so I would refer to rockchip to implement this mapping.
Regards, CK
Noralf.