[PATCH] drm/ast: Inline drm_simple_encoder_init()

[Daniel Vetter]

On Thu, Jun 27, 2024 at 09:18:15AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 26.06.24 um 19:59 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2024 at 11:01:11AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > > 
> > > Am 26.06.24 um 06:34 schrieb Dmitry Baryshkov:
> > > > On Tue, Jun 25, 2024 at 03:18:09PM GMT, Thomas Zimmermann wrote:
> > > > > The function drm_simple_encoder_init() is a trivial helper and
> > > > > deprecated. Replace it with the regular call to drm_encoder_init().
> > > > > Resolves the dependency on drm_simple_kms_helper.h. No functional
> > > > > changes.
> > > > > 
> > > > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
> > > > > ---
> > > > >    drivers/gpu/drm/ast/ast_mode.c | 45 ++++++++++++++++++++++++++++++----
> > > > >    1 file changed, 40 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> > > > > index 6695af70768f..2fd9c78eab73 100644
> > > > > --- a/drivers/gpu/drm/ast/ast_mode.c
> > > > > +++ b/drivers/gpu/drm/ast/ast_mode.c
> > > > > @@ -45,7 +45,6 @@
> > > > >    #include <drm/drm_managed.h>
> > > > >    #include <drm/drm_panic.h>
> > > > >    #include <drm/drm_probe_helper.h>
> > > > > -#include <drm/drm_simple_kms_helper.h>
> > > > >    #include "ast_ddc.h"
> > > > >    #include "ast_drv.h"
> > > > > @@ -1358,6 +1357,14 @@ static int ast_crtc_init(struct drm_device *dev)
> > > > >    	return 0;
> > > > >    }
> > > > > +/*
> > > > > + * VGA Encoder
> > > > > + */
> > > > > +
> > > > > +static const struct drm_encoder_funcs ast_vga_encoder_funcs = {
> > > > > +	.destroy = drm_encoder_cleanup,
> > > > > +};
> > > > > +
> > > > >    /*
> > > > >     * VGA Connector
> > > > >     */
> > > > > @@ -1411,7 +1418,8 @@ static int ast_vga_output_init(struct ast_device *ast)
> > > > >    	struct drm_connector *connector = &ast->output.vga.connector;
> > > > >    	int ret;
> > > > > -	ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
> > > > > +	ret = drm_encoder_init(dev, encoder, &ast_vga_encoder_funcs,
> > > > > +			       DRM_MODE_ENCODER_DAC, NULL);
> > > > What about using drmm_encoder_init() instead? It will call
> > > > drm_encoder_cleanup automatically.
> > > IIRC the original use case for the drmm_encoder_*() funcs was to solve
> > > problems with the clean-up order if the encoder was added dynamically. The
> > > hardware for ast is entirely static and ast uses drmm_mode_config_init() for
> > > auto-cleaning up the modesetting pipeline. Using drmm_encoder_init() seems
> > > like a bit of wasted resources for no gain.
> > The idea of drmm_ is that you use them all. That the managed version of
> > drm_mode_config_init also happens to still work with the unmanaged
> > encoder/connector/crtc/plane cleanup is just to facilitate gradual
> > conversions.
> 
> Sure, I welcome using drmm_ everywhere. I just don't like the fine-grained
> release if that's unnecessary. What most DRM drivers need is in
> drmm_mode_config_init().

Why do you think drmm_mode_config_init is better?

My take is that the point of drmm and devres is that you have really
fine-grained release hooks, so that you never have to write hand-rolled
error handling code anymore. The issue is that when you then try to
combine that with bigger hammer methods like the cleanup callbacks in
drm_mode_config_cleanup, it won't work, because it will interleave
wrongly. And then you're back to hand-rolling all the cleanup code again.
It's a bit an all-or-nothing approach unfortunately, at least for a given
area.

At least my idea was to have drmm_mode_config_init as a transational
helper only, not as the endpoint. At least for anything the driver
allocates/initializes itself, there's still a bunch of things that need to
be cleaned up separately.

Or the other counterpoint: If the global release really is best, then
drm_driver->release is all that's ever needed, and the entire drmm_
infrastructure is kinda pointless. Which yes, strictly speaking it is, at
the cost of typing a lot of error paths.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch