Re: [PATCH] drm/rockchip: Use drm_fbdev_generic_setup()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Rob
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux