Den 04.02.2019 16.01, skrev Rob Herring:
> 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.
>
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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
