Den 19.02.2020 17.23, skrev Daniel Vetter:
> On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> <laurent.pinchart@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx>
>>>>> Cc: Sam Ravnborg <sam@xxxxxxxxxxxx>
>>>>> Cc: Thomas Zimmermann <tzimmermann@xxxxxxx>
>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
>>>>> ---
<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.
Noralf.
> Fun thing is that I've found a pile of missing mutex_destroy and
> ida_cleanup() while reviewing all the code I've read. Not sure I've
> fixed them all up ...
> -Daniel
>
>>
>>>>> }
>>>>> EXPORT_SYMBOL(drm_mode_config_init);
>>>>>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
