[PATCH 4/9] drm/verisilicon: Add gem driver for JH7110 SoC
Thomas Zimmermann
tzimmermann at suse.de
Wed Jun 21 10:44:28 UTC 2023
Hi
Am 19.06.23 um 16:22 schrieb Thomas Zimmermann:
> Hi
>
> Am 02.06.23 um 09:40 schrieb Keith Zhao:
>> This patch implements gem related APIs for JH7100 SoC.
>
> please also see my other reply to this patch. My mail client had a bug
> before I could finish it. Below are some more comments.
>
>>
>> Signed-off-by: Keith Zhao <keith.zhao at starfivetech.com>
>> ---
> [...]
>> +#ifndef __VS_GEM_H__
>> +#define __VS_GEM_H__
>> +
>> +#include <linux/dma-buf.h>
>> +
>> +#include <drm/drm_gem.h>
>> +#include <drm/drm_prime.h>
>> +
>> +#include "vs_drv.h"
>> +/*
>> + *
>> + * @base: drm gem object.
>> + * @size: size requested from user
>> + * @cookie: cookie returned by dma_alloc_attrs
>> + * - not kernel virtual address with DMA_ATTR_NO_KERNEL_MAPPING
>> + * @dma_addr: bus address(accessed by dma) to allocated memory region.
>> + * - this address could be physical address without IOMMU and
>> + * device address with IOMMU.
>> + * @dma_attrs: attribute for DMA API
>> + * @get_pages: flag for manually applying for non-contiguous memory.
>> + * @pages: Array of backing pages.
>> + * @sgt: Imported sg_table.
>> + *
>> + */
>> +struct vs_gem_object {
>> + struct drm_gem_object base;
>> + size_t size;
>> + void *cookie;
>> + dma_addr_t dma_addr;
>> + u32 iova;
>> + unsigned long dma_attrs;
>> + bool get_pages;
>> + struct page **pages;
>> + struct sg_table *sgt;
>> +};
>> +
>> +static inline
>> +struct vs_gem_object *to_vs_gem_object(struct drm_gem_object *obj)
>> +{
>> + return container_of(obj, struct vs_gem_object, base);
>> +}
>> +
>> +struct vs_gem_object *vs_gem_create_object(struct drm_device *dev,
>> + size_t size);
>> +
>> +int vs_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map
>> *map);
>> +void vs_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map
>> *map);
>
> I'd consider this bad style. Your functions are in the vs_ namespace, so
> they should take a vs_gem_object as first argument. Rather implement
> vs_gem_prime_vmap(struct vs_gem_object *vs_obj, struct iosys_map *map)
> and _vunmap() and _mmap().
>
> For the callbacks in struct drm_gemobject_funcs, you can write small
> wrappers around the helpers to do the type casting. See
> drm_gem_shmem_object_mmap() and drm_gem_shmem_mmap() for an example.
>
> https://elixir.bootlin.com/linux/latest/source/include/drm/drm_gem_shmem_helper.h#L233
I was thinking about my advise with the wrappers, but it doesn't seem so
good after all. Maybe just ignore it. I think you should still rename
the function to something like vs_gem_object_vmap(), etc. So they name
reflects that they operate on a struct drm_gem_object.
But many of the helpers in this file are only ever used in vs_gem.c.
You should declare them static in the C file and remove them from this
header.
Best regards
Thomas
>
>
>
>> +
>> +int vs_gem_prime_mmap(struct drm_gem_object *obj,
>> + struct vm_area_struct *vma);
>> +
>> +int vs_gem_dumb_create(struct drm_file *file_priv,
>> + struct drm_device *drm,
>> + struct drm_mode_create_dumb *args);
>> +
>> +int vs_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>> +
>> +struct sg_table *vs_gem_prime_get_sg_table(struct drm_gem_object *obj);
>> +
>> +struct drm_gem_object *vs_gem_prime_import(struct drm_device *dev,
>> + struct dma_buf *dma_buf);
>> +struct drm_gem_object *
>> +vs_gem_prime_import_sg_table(struct drm_device *dev,
>> + struct dma_buf_attachment *attach,
>> + struct sg_table *sgt);
>> +
>> +#endif /* __VS_GEM_H__ */
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230621/2013fd56/attachment.sig>
More information about the dri-devel
mailing list