[01/59] drm/todo: Improve drm_gem_object funcs todo
diff mbox series

Message ID 20190614203615.12639-2-daniel.vetter@ffwll.ch
State New
Headers show
Series
  • prime doc polish and ... a few cleanups
Related show

Commit Message

Daniel Vetter June 14, 2019, 8:35 p.m. UTC
We're kinda going in the wrong direction. Spotted while typing better
gem/prime docs.

Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 Documentation/gpu/todo.rst | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Rob Herring June 14, 2019, 8:44 p.m. UTC | #1
On Fri, Jun 14, 2019 at 2:36 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index b4a76c2703e5..23583f0e3755 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
>  GEM objects can now have a function table instead of having the callbacks on the
>  DRM driver struct. This is now the preferred way and drivers can be moved over.
>
> +Unfortunately some of the recently added GEM helpers are going in the wrong
> +direction by adding OPS macros that use the old, deprecated hooks. See
> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.

At least for DRM_GEM_SHMEM_DRIVER_OPS, it should just be a matter of
removing in the single user (cirrus) and deleting the macro.

Rob
Eric Anholt June 14, 2019, 10:53 p.m. UTC | #2
Daniel Vetter <daniel.vetter@ffwll.ch> writes:

> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

That's a big series, but a great cleanup.  I took a look at a lot of it.
Patch 1-2, 4-10, 41-47, 49-50, and all the gem_prime_import/export drop
patches are:

Reviewed-by: Eric Anholt <eric@anholt.net>

I don't currently have a plan for reading the shuffle in patch 3.
Gerd Hoffmann June 17, 2019, 6:02 a.m. UTC | #3
On Fri, Jun 14, 2019 at 10:35:17PM +0200, Daniel Vetter wrote:
> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
> 
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Daniel Vetter June 17, 2019, 2:03 p.m. UTC | #4
On Fri, Jun 14, 2019 at 03:53:31PM -0700, Eric Anholt wrote:
> Daniel Vetter <daniel.vetter@ffwll.ch> writes:
> 
> > We're kinda going in the wrong direction. Spotted while typing better
> > gem/prime docs.
> >
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Noralf Trønnes <noralf@tronnes.org>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> 
> That's a big series, but a great cleanup.  I took a look at a lot of it.
> Patch 1-2, 4-10, 41-47, 49-50, and all the gem_prime_import/export drop
> patches are:
> 
> Reviewed-by: Eric Anholt <eric@anholt.net>

Thanks a lot for all your review.

> I don't currently have a plan for reading the shuffle in patch 3.

Yeah patch 3 is not cool, I need to split out the shuffle from the doc
rework. Should have done that for v1, but got a bit lazy before the w/e
:-)

Cheers, Daniel
Noralf Trønnes June 17, 2019, 3:47 p.m. UTC | #5
Den 14.06.2019 22.35, skrev Daniel Vetter:
> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
> 
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index b4a76c2703e5..23583f0e3755 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
>  GEM objects can now have a function table instead of having the callbacks on the
>  DRM driver struct. This is now the preferred way and drivers can be moved over.
>  
> +Unfortunately some of the recently added GEM helpers are going in the wrong
> +direction by adding OPS macros that use the old, deprecated hooks. See
> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
> +

Both DRM_GEM_CMA_VMAP_DRIVER_OPS and DRM_GEM_SHMEM_DRIVER_OPS use the
GEM vtable. Or am I missing something here?

Noralf.

>  Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
>  ---------------------------------------------------------
>  
>
Daniel Vetter June 17, 2019, 4:29 p.m. UTC | #6
On Mon, Jun 17, 2019 at 05:47:50PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 14.06.2019 22.35, skrev Daniel Vetter:
> > We're kinda going in the wrong direction. Spotted while typing better
> > gem/prime docs.
> > 
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Noralf Trønnes <noralf@tronnes.org>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  Documentation/gpu/todo.rst | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index b4a76c2703e5..23583f0e3755 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
> >  GEM objects can now have a function table instead of having the callbacks on the
> >  DRM driver struct. This is now the preferred way and drivers can be moved over.
> >  
> > +Unfortunately some of the recently added GEM helpers are going in the wrong
> > +direction by adding OPS macros that use the old, deprecated hooks. See
> > +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
> > +
> 
> Both DRM_GEM_CMA_VMAP_DRIVER_OPS and DRM_GEM_SHMEM_DRIVER_OPS use the
> GEM vtable. Or am I missing something here?

gem vtable I mean drm_gem_object_funcs. Which these macros definitely
aren't useful for.
-Daniel
Noralf Trønnes June 17, 2019, 4:54 p.m. UTC | #7
Den 17.06.2019 18.29, skrev Daniel Vetter:
> On Mon, Jun 17, 2019 at 05:47:50PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 14.06.2019 22.35, skrev Daniel Vetter:
>>> We're kinda going in the wrong direction. Spotted while typing better
>>> gem/prime docs.
>>>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Noralf Trønnes <noralf@tronnes.org>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>  Documentation/gpu/todo.rst | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>>> index b4a76c2703e5..23583f0e3755 100644
>>> --- a/Documentation/gpu/todo.rst
>>> +++ b/Documentation/gpu/todo.rst
>>> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
>>>  GEM objects can now have a function table instead of having the callbacks on the
>>>  DRM driver struct. This is now the preferred way and drivers can be moved over.
>>>  
>>> +Unfortunately some of the recently added GEM helpers are going in the wrong
>>> +direction by adding OPS macros that use the old, deprecated hooks. See
>>> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
>>> +
>>
>> Both DRM_GEM_CMA_VMAP_DRIVER_OPS and DRM_GEM_SHMEM_DRIVER_OPS use the
>> GEM vtable. Or am I missing something here?
> 
> gem vtable I mean drm_gem_object_funcs. Which these macros definitely
> aren't useful for.

#define DRM_GEM_CMA_VMAP_DRIVER_OPS \
	.gem_create_object	= drm_cma_gem_create_object_default_funcs, \
	.dumb_create		= drm_gem_cma_dumb_create, \
	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
	.gem_prime_mmap		= drm_gem_prime_mmap

__drm_gem_cma_create() calls ->gem_create_object.

drm_cma_gem_create_object_default_funcs() sets:
	cma_obj->base.funcs = &drm_cma_gem_default_funcs;

static const struct drm_gem_object_funcs drm_cma_gem_default_funcs = {
	.free = drm_gem_cma_free_object,
	.print_info = drm_gem_cma_print_info,
	.get_sg_table = drm_gem_cma_prime_get_sg_table,
	.vmap = drm_gem_cma_prime_vmap,
	.vm_ops = &drm_gem_cma_vm_ops,
};

The GEM SHMEM helper was made after drm_gem_object_funcs came about so
it sets the default vtable in drm_gem_shmem_create():
		obj->funcs = &drm_gem_shmem_funcs;

static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
	.free = drm_gem_shmem_free_object,
	.print_info = drm_gem_shmem_print_info,
	.pin = drm_gem_shmem_pin,
	.unpin = drm_gem_shmem_unpin,
	.get_sg_table = drm_gem_shmem_get_sg_table,
	.vmap = drm_gem_shmem_vmap,
	.vunmap = drm_gem_shmem_vunmap,
	.vm_ops = &drm_gem_shmem_vm_ops,
};

#define DRM_GEM_SHMEM_DRIVER_OPS \
	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
	.gem_prime_import_sg_table = drm_gem_shmem_prime_import_sg_table, \
	.gem_prime_mmap		= drm_gem_prime_mmap, \
	.dumb_create		= drm_gem_shmem_dumb_create

So the two driver ops macroes only set the necessary bits to enable
prime import/export/mmap and dumb buffer creation, leaving the rest to
drm_gem_object_funcs.
Have we deprecated any of these hooks?

Noralf.
Daniel Vetter June 17, 2019, 9:20 p.m. UTC | #8
On Mon, Jun 17, 2019 at 06:54:04PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 17.06.2019 18.29, skrev Daniel Vetter:
> > On Mon, Jun 17, 2019 at 05:47:50PM +0200, Noralf Trønnes wrote:
> >>
> >>
> >> Den 14.06.2019 22.35, skrev Daniel Vetter:
> >>> We're kinda going in the wrong direction. Spotted while typing better
> >>> gem/prime docs.
> >>>
> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> >>> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >>> Cc: Rob Herring <robh@kernel.org>
> >>> Cc: Noralf Trønnes <noralf@tronnes.org>
> >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >>> ---
> >>>  Documentation/gpu/todo.rst | 4 ++++
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> >>> index b4a76c2703e5..23583f0e3755 100644
> >>> --- a/Documentation/gpu/todo.rst
> >>> +++ b/Documentation/gpu/todo.rst
> >>> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
> >>>  GEM objects can now have a function table instead of having the callbacks on the
> >>>  DRM driver struct. This is now the preferred way and drivers can be moved over.
> >>>  
> >>> +Unfortunately some of the recently added GEM helpers are going in the wrong
> >>> +direction by adding OPS macros that use the old, deprecated hooks. See
> >>> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
> >>> +
> >>
> >> Both DRM_GEM_CMA_VMAP_DRIVER_OPS and DRM_GEM_SHMEM_DRIVER_OPS use the
> >> GEM vtable. Or am I missing something here?
> > 
> > gem vtable I mean drm_gem_object_funcs. Which these macros definitely
> > aren't useful for.
> 
> #define DRM_GEM_CMA_VMAP_DRIVER_OPS \
> 	.gem_create_object	= drm_cma_gem_create_object_default_funcs, \
> 	.dumb_create		= drm_gem_cma_dumb_create, \
> 	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
> 	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
> 	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
> 	.gem_prime_mmap		= drm_gem_prime_mmap
> 
> __drm_gem_cma_create() calls ->gem_create_object.
> 
> drm_cma_gem_create_object_default_funcs() sets:
> 	cma_obj->base.funcs = &drm_cma_gem_default_funcs;
> 
> static const struct drm_gem_object_funcs drm_cma_gem_default_funcs = {
> 	.free = drm_gem_cma_free_object,
> 	.print_info = drm_gem_cma_print_info,
> 	.get_sg_table = drm_gem_cma_prime_get_sg_table,
> 	.vmap = drm_gem_cma_prime_vmap,
> 	.vm_ops = &drm_gem_cma_vm_ops,
> };
> 
> The GEM SHMEM helper was made after drm_gem_object_funcs came about so
> it sets the default vtable in drm_gem_shmem_create():
> 		obj->funcs = &drm_gem_shmem_funcs;
> 
> static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
> 	.free = drm_gem_shmem_free_object,
> 	.print_info = drm_gem_shmem_print_info,
> 	.pin = drm_gem_shmem_pin,
> 	.unpin = drm_gem_shmem_unpin,
> 	.get_sg_table = drm_gem_shmem_get_sg_table,
> 	.vmap = drm_gem_shmem_vmap,
> 	.vunmap = drm_gem_shmem_vunmap,
> 	.vm_ops = &drm_gem_shmem_vm_ops,
> };
> 
> #define DRM_GEM_SHMEM_DRIVER_OPS \
> 	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
> 	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
> 	.gem_prime_import_sg_table = drm_gem_shmem_prime_import_sg_table, \
> 	.gem_prime_mmap		= drm_gem_prime_mmap, \
> 	.dumb_create		= drm_gem_shmem_dumb_create
> 
> So the two driver ops macroes only set the necessary bits to enable
> prime import/export/mmap and dumb buffer creation, leaving the rest to
> drm_gem_object_funcs.
> Have we deprecated any of these hooks?

Uh I was blind :-/ Unfortunately I pushed that patch already, I'll follow
up with a patch to fix it. vram helpers are not following latest best
practices though, right?

Also I guess a lot more of the cma helper using drivers could be cut over
to the vmap ones?
-Daniel
Noralf Trønnes June 17, 2019, 10:12 p.m. UTC | #9
Den 17.06.2019 23.20, skrev Daniel Vetter:
> On Mon, Jun 17, 2019 at 06:54:04PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 17.06.2019 18.29, skrev Daniel Vetter:
>>> On Mon, Jun 17, 2019 at 05:47:50PM +0200, Noralf Trønnes wrote:
>>>>
>>>>
>>>> Den 14.06.2019 22.35, skrev Daniel Vetter:
>>>>> We're kinda going in the wrong direction. Spotted while typing better
>>>>> gem/prime docs.
>>>>>
>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Cc: Noralf Trønnes <noralf@tronnes.org>
>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>>>> ---
>>>>>  Documentation/gpu/todo.rst | 4 ++++
>>>>>  1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>>>>> index b4a76c2703e5..23583f0e3755 100644
>>>>> --- a/Documentation/gpu/todo.rst
>>>>> +++ b/Documentation/gpu/todo.rst
>>>>> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
>>>>>  GEM objects can now have a function table instead of having the callbacks on the
>>>>>  DRM driver struct. This is now the preferred way and drivers can be moved over.
>>>>>  
>>>>> +Unfortunately some of the recently added GEM helpers are going in the wrong
>>>>> +direction by adding OPS macros that use the old, deprecated hooks. See
>>>>> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
>>>>> +
>>>>
>>>> Both DRM_GEM_CMA_VMAP_DRIVER_OPS and DRM_GEM_SHMEM_DRIVER_OPS use the
>>>> GEM vtable. Or am I missing something here?
>>>
>>> gem vtable I mean drm_gem_object_funcs. Which these macros definitely
>>> aren't useful for.
>>
>> #define DRM_GEM_CMA_VMAP_DRIVER_OPS \
>> 	.gem_create_object	= drm_cma_gem_create_object_default_funcs, \
>> 	.dumb_create		= drm_gem_cma_dumb_create, \
>> 	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
>> 	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
>> 	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
>> 	.gem_prime_mmap		= drm_gem_prime_mmap
>>
>> __drm_gem_cma_create() calls ->gem_create_object.
>>
>> drm_cma_gem_create_object_default_funcs() sets:
>> 	cma_obj->base.funcs = &drm_cma_gem_default_funcs;
>>
>> static const struct drm_gem_object_funcs drm_cma_gem_default_funcs = {
>> 	.free = drm_gem_cma_free_object,
>> 	.print_info = drm_gem_cma_print_info,
>> 	.get_sg_table = drm_gem_cma_prime_get_sg_table,
>> 	.vmap = drm_gem_cma_prime_vmap,
>> 	.vm_ops = &drm_gem_cma_vm_ops,
>> };
>>
>> The GEM SHMEM helper was made after drm_gem_object_funcs came about so
>> it sets the default vtable in drm_gem_shmem_create():
>> 		obj->funcs = &drm_gem_shmem_funcs;
>>
>> static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
>> 	.free = drm_gem_shmem_free_object,
>> 	.print_info = drm_gem_shmem_print_info,
>> 	.pin = drm_gem_shmem_pin,
>> 	.unpin = drm_gem_shmem_unpin,
>> 	.get_sg_table = drm_gem_shmem_get_sg_table,
>> 	.vmap = drm_gem_shmem_vmap,
>> 	.vunmap = drm_gem_shmem_vunmap,
>> 	.vm_ops = &drm_gem_shmem_vm_ops,
>> };
>>
>> #define DRM_GEM_SHMEM_DRIVER_OPS \
>> 	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
>> 	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
>> 	.gem_prime_import_sg_table = drm_gem_shmem_prime_import_sg_table, \
>> 	.gem_prime_mmap		= drm_gem_prime_mmap, \
>> 	.dumb_create		= drm_gem_shmem_dumb_create
>>
>> So the two driver ops macroes only set the necessary bits to enable
>> prime import/export/mmap and dumb buffer creation, leaving the rest to
>> drm_gem_object_funcs.
>> Have we deprecated any of these hooks?
> 
> Uh I was blind :-/ Unfortunately I pushed that patch already, I'll follow
> up with a patch to fix it. vram helpers are not following latest best
> practices though, right?

Right.

> 
> Also I guess a lot more of the cma helper using drivers could be cut over
> to the vmap ones?

DRM_GEM_CMA_VMAP_DRIVER_OPS is for drivers that need a virtual address
also on imported buffers. Currently only tinydrm drivers require this.

Other drivers that don't change the defaults could use this:

#define DRM_GEM_CMA_DRIVER_OPS \
	.gem_create_object	= drm_cma_gem_create_object_default_funcs, \
	.dumb_create		= drm_gem_cma_dumb_create, \
	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd, \
	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle, \
	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, \
	.gem_prime_mmap		= drm_gem_prime_mmap

I see that aspeed is a good first candidate for using such a macro since
it's already open coding it.

Noralf.
Thomas Zimmermann June 27, 2019, 12:15 p.m. UTC | #10
Hi

Am 14.06.19 um 22:35 schrieb Daniel Vetter:
> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
> 
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  Documentation/gpu/todo.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index b4a76c2703e5..23583f0e3755 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
>  GEM objects can now have a function table instead of having the callbacks on the
>  DRM driver struct. This is now the preferred way and drivers can be moved over.
>  
> +Unfortunately some of the recently added GEM helpers are going in the wrong
> +direction by adding OPS macros that use the old, deprecated hooks. See
> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.

There's currently only bochs using DRM_GEM_VRAM_DRIVER_PRIME.

Best regards
Thomas

> +
>  Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
>  ---------------------------------------------------------
>  
>

Patch
diff mbox series

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b4a76c2703e5..23583f0e3755 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -228,6 +228,10 @@  struct drm_gem_object_funcs
 GEM objects can now have a function table instead of having the callbacks on the
 DRM driver struct. This is now the preferred way and drivers can be moved over.
 
+Unfortunately some of the recently added GEM helpers are going in the wrong
+direction by adding OPS macros that use the old, deprecated hooks. See
+DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and DRM_GEM_VRAM_DRIVER_PRIME.
+
 Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
 ---------------------------------------------------------