Re: [Intel-gfx] [PATCH 44/44] drm/managed: Cleanup of unused functions and polishing docs

2020-04-05 Thread Noralf Trønnes


Den 03.04.2020 15.58, skrev Daniel Vetter:
> Following functions are only used internally, not by drivers:
> - drm_dev_init
> - devm_drm_dev_init
> - drmm_add_final_kfree
> 
> Also, now that we have a very slick and polished way to allocate a
> drm_device with devm_drm_dev_alloc, update all the docs to reflect the
> new reality. Mostly this consists of deleting old and misleading
> hints. Two main ones:
> 
> - it is no longer required that the drm_device base class is first in
>   the structure. devm_drm_dev_alloc can cope with it being anywhere
> 
> - obviously embedded no needs devm_drm_dev_alloc

s/no/now/ ?

> 
> Signed-off-by: Daniel Vetter 
> ---



> @@ -240,13 +240,13 @@ void drm_minor_release(struct drm_minor *minor)
>   * DOC: driver instance overview
>   *
>   * A device instance for a drm driver is represented by  drm_device. 
> This
> - * is initialized with drm_dev_init(), usually from bus-specific ->probe()
> - * callbacks implemented by the driver. The driver then needs to initialize 
> all
> - * the various subsystems for the drm device like memory management, vblank
> - * handling, modesetting support and intial output configuration plus 
> obviously
> - * initialize all the corresponding hardware bits. Finally when everything 
> is up
> - * and running and ready for userspace the device instance can be published
> - * using drm_dev_register().
> + * is allocated and initialized with devm_drm_dev_alloc(), usually from
> + * bus-specific ->probe() callbacks implemented by the driver. The driver 
> then
> + * needs to initialize all the various subsystems for the drm device like 
> memory
> + * management, vblank handling, modesetting support and intial output

s/intial/initial/

> + * configuration plus obviously initialize all the corresponding hardware 
> bits.
> + * Finally when everything is up and running and ready for userspace the 
> device
> + * instance can be published using drm_dev_register().
>   *
>   * There is also deprecated support for initalizing device instances using
>   * bus-specific helpers and the _driver.load callback. But due to



> @@ -767,19 +706,9 @@ EXPORT_SYMBOL(__devm_drm_dev_alloc);
>   * @driver: DRM driver to allocate device for
>   * @parent: Parent device object
>   *
> - * Allocate and initialize a new DRM device. No device registration is done.
> - * Call drm_dev_register() to advertice the device to user space and 
> register it
> - * with other core subsystems. This should be done last in the device
> - * initialization sequence to make sure userspace can't access an 
> inconsistent
> - * state.
> - *
> - * The initial ref-count of the object is 1. Use drm_dev_get() and
> - * drm_dev_put() to take and drop further ref-counts.
> - *
> - * Note that for purely virtual devices @parent can be NULL.
> - *
> - * Drivers that wish to subclass or embed  drm_device into their
> - * own struct should look at using drm_dev_init() instead.
> + * This is the deprecated version of devm_drm_dev_alloc(), which doesn not 
> support

s/doesn/does/

> + * subclassing through embedding the struct _device in a driver private
> + * structure, and which does not support automatic cleanup through devres.
>   *
>   * RETURNS:
>   * Pointer to new DRM device, or ERR_PTR on failure.

Acked-by: Noralf Trønnes 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 44/44] drm/managed: Cleanup of unused functions and polishing docs

2020-04-03 Thread Daniel Vetter
Following functions are only used internally, not by drivers:
- drm_dev_init
- devm_drm_dev_init
- drmm_add_final_kfree

Also, now that we have a very slick and polished way to allocate a
drm_device with devm_drm_dev_alloc, update all the docs to reflect the
new reality. Mostly this consists of deleting old and misleading
hints. Two main ones:

- it is no longer required that the drm_device base class is first in
  the structure. devm_drm_dev_alloc can cope with it being anywhere

- obviously embedded no needs devm_drm_dev_alloc

Signed-off-by: Daniel Vetter 
---
 .../driver-api/driver-model/devres.rst|   2 +-
 drivers/gpu/drm/drm_drv.c | 119 --
 drivers/gpu/drm/drm_internal.h|   1 +
 drivers/gpu/drm/drm_managed.c |  15 +--
 include/drm/drm_device.h  |   2 +-
 include/drm/drm_drv.h |  20 +--
 6 files changed, 34 insertions(+), 125 deletions(-)

diff --git a/Documentation/driver-api/driver-model/devres.rst 
b/Documentation/driver-api/driver-model/devres.rst
index 46c13780994c..74a4a3fa8c52 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -263,7 +263,7 @@ DMA
   dmam_pool_destroy()
 
 DRM
-  devm_drm_dev_init()
+  devm_drm_dev_alloc()
 
 GPIO
   devm_gpiod_get()
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9e60b784b3ac..64e20c630aa7 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -240,13 +240,13 @@ void drm_minor_release(struct drm_minor *minor)
  * DOC: driver instance overview
  *
  * A device instance for a drm driver is represented by  drm_device. 
This
- * is initialized with drm_dev_init(), usually from bus-specific ->probe()
- * callbacks implemented by the driver. The driver then needs to initialize all
- * the various subsystems for the drm device like memory management, vblank
- * handling, modesetting support and intial output configuration plus obviously
- * initialize all the corresponding hardware bits. Finally when everything is 
up
- * and running and ready for userspace the device instance can be published
- * using drm_dev_register().
+ * is allocated and initialized with devm_drm_dev_alloc(), usually from
+ * bus-specific ->probe() callbacks implemented by the driver. The driver then
+ * needs to initialize all the various subsystems for the drm device like 
memory
+ * management, vblank handling, modesetting support and intial output
+ * configuration plus obviously initialize all the corresponding hardware bits.
+ * Finally when everything is up and running and ready for userspace the device
+ * instance can be published using drm_dev_register().
  *
  * There is also deprecated support for initalizing device instances using
  * bus-specific helpers and the _driver.load callback. But due to
@@ -274,7 +274,7 @@ void drm_minor_release(struct drm_minor *minor)
  *
  * The following example shows a typical structure of a DRM display driver.
  * The example focus on the probe() function and the other functions that is
- * almost always present and serves as a demonstration of devm_drm_dev_init().
+ * almost always present and serves as a demonstration of devm_drm_dev_alloc().
  *
  * .. code-block:: c
  *
@@ -294,22 +294,12 @@ void drm_minor_release(struct drm_minor *minor)
  * struct drm_device *drm;
  * int ret;
  *
- * // devm_kzalloc() can't be used here because the drm_device '
- * // lifetime can exceed the device lifetime if driver unbind
- * // happens when userspace still has open file descriptors.
- * priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- * if (!priv)
- * return -ENOMEM;
- *
+ * priv = devm_drm_dev_alloc(>dev, _drm_driver,
+ *   struct driver_device, drm);
+ * if (IS_ERR(priv))
+ * return PTR_ERR(priv);
  * drm = >drm;
  *
- * ret = devm_drm_dev_init(>dev, drm, _drm_driver);
- * if (ret) {
- * kfree(priv);
- * return ret;
- * }
- * drmm_add_final_kfree(drm, priv);
- *
  * ret = drmm_mode_config_init(drm);
  * if (ret)
  * return ret;
@@ -550,9 +540,9 @@ static void drm_fs_inode_free(struct inode *inode)
  * following guidelines apply:
  *
  *  - The entire device initialization procedure should be run from the
- *_master_ops.master_bind callback, starting with drm_dev_init(),
- *then binding all components with component_bind_all() and finishing with
- *drm_dev_register().
+ *_master_ops.master_bind callback, starting with
+ *devm_drm_dev_alloc(), then binding all components with
+ *component_bind_all() and finishing with drm_dev_register().
  *
  *  - The opaque pointer passed to all