[Intel-gfx] [PATCH 27/52] drm: Manage drm_mode_config_init with drmm_

[Daniel Vetter]

On Wed, Feb 19, 2020 at 6:30 PM Noralf Trønnes <noralf at tronnes.org> wrote:
>
>
>
> Den 19.02.2020 17.23, skrev Daniel Vetter:
> > On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> > <laurent.pinchart at ideasonboard.com> wrote:
> >>
> >> Hi Daniel,
> >>
> >> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> >>>> On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> >>>>> drm_mode_config_cleanup is idempotent, so no harm in calling this
> >>>>> twice. This allows us to gradually switch drivers over by removing
> >>>>> explicit drm_mode_config_cleanup calls.
> >>>>>
> >>>>> With this step it's not also possible that (at least for simple
> >>>>> drivers) automatic resource cleanup can be done correctly without a
> >>>>> drm_driver->release hook. Therefore allow this now in
> >>>>> devm_drm_dev_init().
> >>>>>
> >>>>> Also with drmm_ explicit drm_driver->release hooks are kinda not the
> >>>>> best option, so deprecate that hook to discourage future users.
> >>>>>
> >>>>> v2: Fixup the example in the kerneldoc too.
> >>>>>
> >>>>> Cc: "Noralf Trønnes" <noralf at tronnes.org>
> >>>>> Cc: Sam Ravnborg <sam at ravnborg.org>
> >>>>> Cc: Thomas Zimmermann <tzimmermann at suse.de>
> >>>>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> >>>>> ---
>
> <snip>
>
> >>>>> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> >>>>> index 08e6eff6a179..957db1edba0c 100644
> >>>>> --- a/drivers/gpu/drm/drm_mode_config.c
> >>>>> +++ b/drivers/gpu/drm/drm_mode_config.c
> >>>>> @@ -25,6 +25,7 @@
> >>>>>  #include <drm/drm_drv.h>
> >>>>>  #include <drm/drm_encoder.h>
> >>>>>  #include <drm/drm_file.h>
> >>>>> +#include <drm/drm_managed.h>
> >>>>>  #include <drm/drm_mode_config.h>
> >>>>>  #include <drm/drm_print.h>
> >>>>>  #include <linux/dma-resv.h>
> >>>>> @@ -373,6 +374,11 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
> >>>>>       return 0;
> >>>>>  }
> >>>>>
> >>>>> +static void drm_mode_config_init_release(struct drm_device *dev, void *ptr)
> >>>>> +{
> >>>>> +     drm_mode_config_cleanup(dev);
> >>>>> +}
> >>>>> +
> >>>>>  /**
> >>>>>   * drm_mode_config_init - initialize DRM mode_configuration structure
> >>>>>   * @dev: DRM device
> >>>>> @@ -384,8 +390,10 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
> >>>>>   * problem, since this should happen single threaded at init time. It is the
> >>>>>   * driver's problem to ensure this guarantee.
> >>>>>   *
> >>>>> + * Cleanup is automatically handled through registering drm_mode_config_cleanup
> >>>>> + * with drmm_add_action().
> >>>>>   */
> >>>>> -void drm_mode_config_init(struct drm_device *dev)
> >>>>> +int drm_mode_config_init(struct drm_device *dev)
> >>>>>  {
> >>>>>       mutex_init(&dev->mode_config.mutex);
> >>>>>       drm_modeset_lock_init(&dev->mode_config.connection_mutex);
> >>>>> @@ -443,6 +451,8 @@ void drm_mode_config_init(struct drm_device *dev)
> >>>>>               drm_modeset_acquire_fini(&modeset_ctx);
> >>>>>               dma_resv_fini(&resv);
> >>>>>       }
> >>>>> +
> >>>>> +     return drmm_add_action(dev, drm_mode_config_init_release, NULL);
> >>>>
> >>>> If this fails, shouldn't drm_mode_config_cleanup() be called here ?
> >>>
> >>> Maybe for ocd reasons, but not for actually cleaning up anything. It's
> >>> just a bunch of empty lists that drm_mode_config_cleanup will walk and
> >>> do nothing about. Not sure I should add that ...
> >>
> >> How about the ida init, and the mutex_init() that isn't a no-op when
> >> lock debugging is enabled ?
> >
> > Hm right, I'll fix this.
> >
>
> You could make a drmm_ version of devm_add_action_or_reset() for this.

...

How did I not see that in devres.c. In my defense, I've never written
a driver using devm because of all the lifetime bugs that would cause
in drm, but yes this is exactly what we want here.

Thanks a lot for the pointer, I'll go do some typing!

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch