Displaying 4 results from an estimated 4 matches for "drmm_kzalloc".
Did you mean:
devm_kzalloc
2020 Mar 02
2
[PATCH 28/51] drm/bochs: Drop explicit drm_mode_config_cleanup
Instead rely on the automatic clean, for which we just need to check
that drm_mode_config_init succeeded. To avoid an inversion in the
cleanup we also have to move the dev_private allocation over to
drmm_kzalloc.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
v2: Explain why this cleanup is possible (Laurent...
2020 Feb 19
0
[PATCH 29/52] drm/bochs: Drop explicit drm_mode_config_cleanup
Instead rely on the automatic clean, for which we just need to check
that drm_mode_config_init succeeded. To avoid an inversion in the
cleanup we also have to move the dev_private allocation over to
drmm_kzalloc.
Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Cc: Gerd Hoffmann <kraxel at redhat.com>
Cc: virtualization at lists.linux-foundation.org
---
drivers/gpu/drm/bochs/bochs.h | 1 -
drivers/gpu/drm/bochs/bochs_drv.c | 6 ++----
drivers/gpu/drm/bochs/bochs_kms.c | 14 ++++...
2024 Sep 26
1
[PATCH v5 79/80] drm/omapdrm: Remove struct drm_fb_helper from struct omap_fbdev.
...8 @@ void omap_fbdev_setup(struct drm_device *dev)
> drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
> drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n");
>
> - fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
> + fbdev = drmm_kzalloc(dev, sizeof(*fbdev), GFP_KERNEL);
> if (!fbdev)
> return;
> - helper = &fbdev->base;
> + fbdev->dev = dev;
> + INIT_WORK(&fbdev->work, pan_worker);
> +
> + priv->fbdev = fbdev;
>
> + helper = kzalloc(sizeof(*helper), GFP_KERNEL);
> + if (!...
2024 Jul 28
1
[PATCH v2 02/37] drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common code
On Sun, Jul 28, 2024 at 11:34:14PM +0200, Danilo Krummrich wrote:
> On Sun, Jul 28, 2024 at 03:13:08PM -0300, Jason Gunthorpe wrote:
> I think we're on the same page with all that. As clarified in [1], that's not a
> big concern, I was referring to the changes required to integrate the auxbus
> stuff.
Well, I see this thread having the realization that things are not
setup