search for: drm_encoder_init_nofuncs

...gt; > As the cleanup is handled automatically when the drm device > is teared down (in mode_config_rest()) I considered if we could here > use the drmm_ namespace - but that felt wrong. > > My proposal is the following: > - Move the implementation to drm_encoder.c > - Name it drm_encoder_init_nofuncs() Or better, rename the existing drm_encoder_init() to drm_encoder_init_funcs(), and rename drm_simple_encoder_init() to drm_encoder_init() ? It's the common case. > The patches posted in this thread would be a little simpler > as they would loose the added include file. > And the th...

Hi Laurent Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > Hi Thomas, > > Thank you for the patch. > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: >> A call to drm_simple_encoder_init() initializes an encoder without >> further functionality. It only provides the destroy callback to >> cleanup the encoder's state. Only few drivers

Hi Laurent Am 06.03.20 um 15:22 schrieb Laurent Pinchart: > Hi Thomas, > > Thank you for the patch. > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote: >> A call to drm_simple_encoder_init() initializes an encoder without >> further functionality. It only provides the destroy callback to >> cleanup the encoder's state. Only few drivers

...he default as provided by drm_simple_* As the cleanup is handled automatically when the drm device is teared down (in mode_config_rest()) I considered if we could here use the drmm_ namespace - but that felt wrong. My proposal is the following: - Move the implementation to drm_encoder.c - Name it drm_encoder_init_nofuncs() The patches posted in this thread would be a little simpler as they would loose the added include file. And the three drivers using the current infrastructure would need a small update. I you decide to keep the current approach where the functions are in drm_simple_* then the full series is: Ac...