On Mon, Feb 4, 2019 at 9:01 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Sat, Feb 2, 2019 at 12:22 PM Noralf Trønnes <noralf@xxxxxxxxxxx> 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.
As another data point, exynos always uses DMA_ATTR_NO_KERNEL_MAPPING
and then vmap's its fbdev buffer.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
