All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 01/59] drm: Add devm_drm_dev_alloc macro
Date: Tue, 21 Apr 2020 12:45:49 +0200	[thread overview]
Message-ID: <CAKMK7uH2vhrQ7eTTF1B+==UJS9ZxhDv2RDvR0ct4P0vVJobf=w@mail.gmail.com> (raw)
In-Reply-To: <4d5229c2-acb4-b76f-13c7-88a5f3de4760@suse.de>

On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
> > Add a new macro helper to combine the usual init sequence in drivers,
> > consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
> > triplet. This allows us to remove the rather unsightly
> > drmm_add_final_kfree from all currently merged drivers.
> >
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since once all drivers
> > are converted over to devm_drm_dev_alloc we can unexport a lot of
> > interim functions and make the documentation for driver authors a lot
> > cleaner and less confusing. There will be only one true way to
> > initialize a drm_device at the end of this, which is going to be
> > devm_drm_dev_alloc.
> >
> > v2:
> > - Actually explain what this is for in the commit message (Sam)
> > - Fix checkpatch issues (Sam)
> >
> > Acked-by: Noralf Trønnes <noralf@tronnes.org>
> > Cc: Noralf Trønnes <noralf@tronnes.org>
> > Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Thanks for taking a look, some questions on your suggestions below.

> Sorry for being late. A number of nits are listed below. In any case:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Best regards
> Thomas
>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 23 +++++++++++++++++++++++
> >  include/drm/drm_drv.h     | 33 +++++++++++++++++++++++++++++++++
> >  2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 1bb4f636b83c..8e1813d2a12e 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> >  }
> >  EXPORT_SYMBOL(devm_drm_dev_init);
> >
> > +void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> > +                        size_t size, size_t offset)
>
> Maybe rename 'offset' of 'dev_offset' to make the relationship clear.

Hm, I see the point of this (and the dev_field below, although I'd go
with dev_member there for some consistency with other macros using
offset_of or container_of), but I'm not sure about the dev_ prefix.
Drivers use that sometimes for the struct device *, and usage for
struct drm_device * is also very inconsistent. I've seen ddev, drm,
dev and base (that one only for embedded structs ofc). So not sure
which prefix to pick, aside from dev_ seems the most confusing. Got
ideas?

> > +{
> > +     void *container;
> > +     struct drm_device *drm;
> > +     int ret;
> > +
> > +     container = kzalloc(size, GFP_KERNEL);
> > +     if (!container)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     drm = container + offset;
>
> While convenient, I somewhat dislike the use of void* variables. I'd use
> unsigned char* for container and do an explicit cast to struct
> drm_device* here.

I thought ever since C89 the explicit recommendation for untyped
pointer math has been void *, and no longer char *, with the spec
being explicit that void * pointer math works exactly like char *. So
not clear on why you think char * is preferred here. I'm also not
aware of any other kernel code that casts to char * for untyped
pointer math. So unless you have some supporting evidence, I'll skip
this one, ok?

Thanks, Daniel

> > +     ret = devm_drm_dev_init(parent, drm, driver);
> > +     if (ret) {
> > +             kfree(container);
> > +             return ERR_PTR(ret);
> > +     }
> > +     drmm_add_final_kfree(drm, container);
> > +
> > +     return container;
> > +}
> > +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> > +
> >  /**
> >   * drm_dev_alloc - Allocate new DRM device
> >   * @driver: DRM driver to allocate device for
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index e7c6ea261ed1..f07f15721254 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -626,6 +626,39 @@ int devm_drm_dev_init(struct device *parent,
> >                     struct drm_device *dev,
> >                     struct drm_driver *driver);
> >
> > +void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> > +                        size_t size, size_t offset);
> > +
> > +/**
> > + * devm_drm_dev_alloc - Resource managed allocation of a &drm_device instance
> > + * @parent: Parent device object
> > + * @driver: DRM driver
> > + * @type: the type of the struct which contains struct &drm_device
> > + * @member: the name of the &drm_device within @type.
> > + *
> > + * This allocates 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.
> > + *
> > + * It is recommended that drivers embed &struct drm_device into their own device
> > + * structure.
> > + *
> > + * Note that this manages the lifetime of the resulting &drm_device
> > + * automatically using devres. The DRM device initialized with this function is
> > + * automatically put on driver detach using drm_dev_put().
> > + *
> > + * RETURNS:
> > + * Pointer to new DRM device, or ERR_PTR on failure.
> > + */
> > +#define devm_drm_dev_alloc(parent, driver, type, member) \
>
> I'd replace 'member' with 'dev_field' to make the relation ship clear.
>
> > +     ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \
> > +                                    offsetof(type, member)))
> > +
> >  struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> >                                struct device *parent);
> >  int drm_dev_register(struct drm_device *dev, unsigned long flags);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [Intel-gfx] [PATCH 01/59] drm: Add devm_drm_dev_alloc macro
Date: Tue, 21 Apr 2020 12:45:49 +0200	[thread overview]
Message-ID: <CAKMK7uH2vhrQ7eTTF1B+==UJS9ZxhDv2RDvR0ct4P0vVJobf=w@mail.gmail.com> (raw)
In-Reply-To: <4d5229c2-acb4-b76f-13c7-88a5f3de4760@suse.de>

On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
> > Add a new macro helper to combine the usual init sequence in drivers,
> > consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
> > triplet. This allows us to remove the rather unsightly
> > drmm_add_final_kfree from all currently merged drivers.
> >
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since once all drivers
> > are converted over to devm_drm_dev_alloc we can unexport a lot of
> > interim functions and make the documentation for driver authors a lot
> > cleaner and less confusing. There will be only one true way to
> > initialize a drm_device at the end of this, which is going to be
> > devm_drm_dev_alloc.
> >
> > v2:
> > - Actually explain what this is for in the commit message (Sam)
> > - Fix checkpatch issues (Sam)
> >
> > Acked-by: Noralf Trønnes <noralf@tronnes.org>
> > Cc: Noralf Trønnes <noralf@tronnes.org>
> > Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Thanks for taking a look, some questions on your suggestions below.

> Sorry for being late. A number of nits are listed below. In any case:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Best regards
> Thomas
>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 23 +++++++++++++++++++++++
> >  include/drm/drm_drv.h     | 33 +++++++++++++++++++++++++++++++++
> >  2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 1bb4f636b83c..8e1813d2a12e 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> >  }
> >  EXPORT_SYMBOL(devm_drm_dev_init);
> >
> > +void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> > +                        size_t size, size_t offset)
>
> Maybe rename 'offset' of 'dev_offset' to make the relationship clear.

Hm, I see the point of this (and the dev_field below, although I'd go
with dev_member there for some consistency with other macros using
offset_of or container_of), but I'm not sure about the dev_ prefix.
Drivers use that sometimes for the struct device *, and usage for
struct drm_device * is also very inconsistent. I've seen ddev, drm,
dev and base (that one only for embedded structs ofc). So not sure
which prefix to pick, aside from dev_ seems the most confusing. Got
ideas?

> > +{
> > +     void *container;
> > +     struct drm_device *drm;
> > +     int ret;
> > +
> > +     container = kzalloc(size, GFP_KERNEL);
> > +     if (!container)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     drm = container + offset;
>
> While convenient, I somewhat dislike the use of void* variables. I'd use
> unsigned char* for container and do an explicit cast to struct
> drm_device* here.

I thought ever since C89 the explicit recommendation for untyped
pointer math has been void *, and no longer char *, with the spec
being explicit that void * pointer math works exactly like char *. So
not clear on why you think char * is preferred here. I'm also not
aware of any other kernel code that casts to char * for untyped
pointer math. So unless you have some supporting evidence, I'll skip
this one, ok?

Thanks, Daniel

> > +     ret = devm_drm_dev_init(parent, drm, driver);
> > +     if (ret) {
> > +             kfree(container);
> > +             return ERR_PTR(ret);
> > +     }
> > +     drmm_add_final_kfree(drm, container);
> > +
> > +     return container;
> > +}
> > +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> > +
> >  /**
> >   * drm_dev_alloc - Allocate new DRM device
> >   * @driver: DRM driver to allocate device for
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index e7c6ea261ed1..f07f15721254 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -626,6 +626,39 @@ int devm_drm_dev_init(struct device *parent,
> >                     struct drm_device *dev,
> >                     struct drm_driver *driver);
> >
> > +void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> > +                        size_t size, size_t offset);
> > +
> > +/**
> > + * devm_drm_dev_alloc - Resource managed allocation of a &drm_device instance
> > + * @parent: Parent device object
> > + * @driver: DRM driver
> > + * @type: the type of the struct which contains struct &drm_device
> > + * @member: the name of the &drm_device within @type.
> > + *
> > + * This allocates 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.
> > + *
> > + * It is recommended that drivers embed &struct drm_device into their own device
> > + * structure.
> > + *
> > + * Note that this manages the lifetime of the resulting &drm_device
> > + * automatically using devres. The DRM device initialized with this function is
> > + * automatically put on driver detach using drm_dev_put().
> > + *
> > + * RETURNS:
> > + * Pointer to new DRM device, or ERR_PTR on failure.
> > + */
> > +#define devm_drm_dev_alloc(parent, driver, type, member) \
>
> I'd replace 'member' with 'dev_field' to make the relation ship clear.
>
> > +     ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \
> > +                                    offsetof(type, member)))
> > +
> >  struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> >                                struct device *parent);
> >  int drm_dev_register(struct drm_device *dev, unsigned long flags);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-04-21 10:46 UTC|newest]

Thread overview: 317+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15  7:39 [PATCH 00/59] devm_drm_dev_alloc, v2 Daniel Vetter
2020-04-15  7:39 ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 01/59] drm: Add devm_drm_dev_alloc macro Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-20 13:36   ` Thomas Zimmermann
2020-04-20 13:36     ` [Intel-gfx] " Thomas Zimmermann
2020-04-21 10:45     ` Daniel Vetter [this message]
2020-04-21 10:45       ` Daniel Vetter
2020-04-21 14:03       ` Thomas Zimmermann
2020-04-21 14:03         ` [Intel-gfx] " Thomas Zimmermann
2020-04-21 20:32         ` Sam Ravnborg
2020-04-21 20:32           ` [Intel-gfx] " Sam Ravnborg
2020-04-28 13:06           ` Daniel Vetter
2020-04-28 13:06             ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 02/59] drm/vboxvideo: drop DRM_MTRR_WC #define Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:01   ` Hans de Goede
2020-04-15 15:01     ` [Intel-gfx] " Hans de Goede
2020-04-15  7:39 ` [PATCH 03/59] drm/vboxvideo: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:02   ` Hans de Goede
2020-04-15 15:02     ` [Intel-gfx] " Hans de Goede
2020-04-24 16:33   ` Sam Ravnborg
2020-04-24 16:33     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:39 ` [PATCH 04/59] drm/vboxvideo: Stop using drm_device->dev_private Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:02   ` Hans de Goede
2020-04-15 15:02     ` [Intel-gfx] " Hans de Goede
2020-04-15  7:39 ` [PATCH 05/59] drm/vboxvidoe: use managed pci functions Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:03   ` Hans de Goede
2020-04-15 15:03     ` [Intel-gfx] " Hans de Goede
2020-04-15 17:44     ` Daniel Vetter
2020-04-15 17:44       ` [Intel-gfx] " Daniel Vetter
2020-04-20 13:16       ` Hans de Goede
2020-04-20 13:16         ` [Intel-gfx] " Hans de Goede
2020-04-15 17:32   ` Thomas Zimmermann
2020-04-15 17:32     ` [Intel-gfx] " Thomas Zimmermann
2020-04-15  7:39 ` [PATCH 06/59] drm/vboxvideo: Use devm_gen_pool_create Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:04   ` Hans de Goede
2020-04-15 15:04     ` [Intel-gfx] " Hans de Goede
2020-04-15  7:39 ` [PATCH 07/59] drm/v3d: Don't set drm_device->dev_private Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 08/59] drm/v3d: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 09/59] drm/v3d: Delete v3d_dev->dev Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 10/59] drm/v3d: Delete v3d_dev->pdev Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 11/59] drm/udl: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:55   ` Thomas Zimmermann
2020-04-15  7:55     ` [Intel-gfx] " Thomas Zimmermann
2020-04-24 14:55   ` Sam Ravnborg
2020-04-24 14:55     ` [Intel-gfx] " Sam Ravnborg
2020-04-28 13:18     ` Daniel Vetter
2020-04-28 13:18       ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 12/59] drm/udl: don't set drm_device->dev_private Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 13/59] drm/st7735r: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 14/59] drm/st7586: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 15/59] drm/repaper: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 16/59] drm/mi0283qt: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 17/59] drm/ili9486: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 18/59] drm/ili9341: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 19/59] drm/ili9225: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 20/59] drm/hx8357d: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:39 ` [PATCH 21/59] drm/gm12u320: " Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:04   ` Hans de Goede
2020-04-15 15:04     ` [Intel-gfx] " Hans de Goede
2020-04-15  7:39 ` [PATCH 22/59] drm/gm12u320: Don't use drm_device->dev_private Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-15 15:05   ` Hans de Goede
2020-04-15 15:05     ` [Intel-gfx] " Hans de Goede
2020-04-15  7:39 ` [PATCH 23/59] drm/tidss: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-21 11:03   ` Tomi Valkeinen
2020-04-21 11:03     ` [Intel-gfx] " Tomi Valkeinen
2020-04-15  7:39 ` [PATCH 24/59] drm/tidss: Don't use drm_device->dev_private Daniel Vetter
2020-04-15  7:39   ` [Intel-gfx] " Daniel Vetter
2020-04-21 11:05   ` Tomi Valkeinen
2020-04-21 11:05     ` [Intel-gfx] " Tomi Valkeinen
2020-04-15  7:40 ` [PATCH 25/59] drm/tidss: Delete tidss->saved_state Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-21 11:05   ` Tomi Valkeinen
2020-04-21 11:05     ` [Intel-gfx] " Tomi Valkeinen
2020-04-15  7:40 ` [PATCH 26/59] drm/qxl: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-24 15:09   ` Sam Ravnborg
2020-04-24 15:09     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 15:09     ` Sam Ravnborg
2020-04-28 14:00     ` Daniel Vetter
2020-04-28 14:00       ` [Intel-gfx] " Daniel Vetter
2020-04-28 14:00       ` Daniel Vetter
2020-04-28 17:00       ` Sam Ravnborg
2020-04-28 17:00         ` [Intel-gfx] " Sam Ravnborg
2020-04-28 17:00         ` Sam Ravnborg
2020-04-28 18:04         ` Daniel Vetter
2020-04-28 18:04           ` [Intel-gfx] " Daniel Vetter
2020-04-28 18:04           ` Daniel Vetter
2020-04-15  7:40 ` [PATCH 27/59] drm/qxl: Don't use drm_device->dev_private Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-24 15:12   ` Sam Ravnborg
2020-04-24 15:12     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 15:12     ` Sam Ravnborg
2020-04-15  7:40 ` [PATCH 28/59] drm/mcde: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15 12:20   ` Linus Walleij
2020-04-15 12:20     ` [Intel-gfx] " Linus Walleij
2020-04-15  7:40 ` [PATCH 29/59] drm/mcde: Don't use drm_device->dev_private Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 30/59] drm/ingenic: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 31/59] drm/ingenic: Don't set drm_device->dev_private Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 32/59] drm/komeda: use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 33/59] drm/armada: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 34/59] drm/armada: Don't use drm_device->dev_private Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 35/59] drm/cirrus: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-15  7:40 ` [PATCH 36/59] drm/cirrus: Don't use drm_device->dev_private Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-15  7:40 ` [PATCH 37/59] drm/cirrus: Move to drm/tiny Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-15  8:01   ` Thomas Zimmermann
2020-04-15  8:01     ` [Intel-gfx] " Thomas Zimmermann
2020-04-15  8:01     ` Thomas Zimmermann
2020-04-15  8:19     ` Daniel Vetter
2020-04-15  8:19       ` [Intel-gfx] " Daniel Vetter
2020-04-15  8:19       ` Daniel Vetter
2020-04-15  8:46       ` Thomas Zimmermann
2020-04-15  8:46         ` [Intel-gfx] " Thomas Zimmermann
2020-04-15  8:46         ` Thomas Zimmermann
2020-04-15  9:31         ` Daniel Vetter
2020-04-15  9:31           ` [Intel-gfx] " Daniel Vetter
2020-04-15  9:31           ` Daniel Vetter
2020-04-21  7:37   ` Gerd Hoffmann
2020-04-21  7:37     ` [Intel-gfx] " Gerd Hoffmann
2020-04-21  7:37     ` Gerd Hoffmann
2020-04-24 16:37   ` Sam Ravnborg
2020-04-24 16:37     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 16:37     ` Sam Ravnborg
2020-04-15  7:40 ` [PATCH 38/59] drm/i915: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-28 18:52   ` Daniel Vetter
2020-04-28 18:52     ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 39/59] drm/arcpgu: Switch to devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 16:43   ` Sam Ravnborg
2020-04-24 16:43     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 40/59] drm/arcpgu: Stop using drm_device->dev_private Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 16:46   ` Sam Ravnborg
2020-04-24 16:46     ` [Intel-gfx] " Sam Ravnborg
2020-09-04 13:42     ` Daniel Vetter
2020-09-04 13:42       ` [Intel-gfx] " Daniel Vetter
2020-09-04 14:42       ` Sam Ravnborg
2020-09-04 14:42         ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 41/59] drm/arcpgu: Delete arcpgu_priv->fb Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 16:47   ` Sam Ravnborg
2020-04-24 16:47     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 42/59] drm/arc: Embedded a drm_simple_display_pipe Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:34   ` Sam Ravnborg
2020-04-24 17:34     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 43/59] drm/arc: Embedd a drm_connector for sim case Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:34   ` Sam Ravnborg
2020-04-24 17:34     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 44/59] drm/arc: Drop surplus connector registration Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 16:51   ` Sam Ravnborg
2020-04-24 16:51     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 45/59] drm/arc: Use drmm_mode_config_cleanup Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:36   ` Sam Ravnborg
2020-04-24 17:36     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 46/59] drm/arc: Align with simple pipe helpers Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-25 12:24   ` Sam Ravnborg
2020-04-25 12:24     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 47/59] drm/arc: Convert to drm_simple_kms_pipe_helper Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:40   ` Sam Ravnborg
2020-04-24 17:40     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 48/59] drm/arc: Drop fb/crtc check in arc_pgu_update Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:45   ` Sam Ravnborg
2020-04-24 17:45     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 49/59] drm/arc: Inline arcpgu_crtc.c Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:51   ` Sam Ravnborg
2020-04-24 17:51     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 50/59] drm/arc: Inline arcpgu_drm_hdmi_init Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:54   ` Sam Ravnborg
2020-04-24 17:54     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 51/59] drm/arc: Inline remaining files Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:56   ` Sam Ravnborg
2020-04-24 17:56     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 52/59] drm/arc: Initialize sim connector before display pipe Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-24 17:58   ` Sam Ravnborg
2020-04-24 17:58     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 53/59] drm/arc: Move to drm/tiny Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  8:04   ` Thomas Zimmermann
2020-04-15  8:04     ` [Intel-gfx] " Thomas Zimmermann
2020-04-15  8:22     ` Daniel Vetter
2020-04-15  8:22       ` [Intel-gfx] " Daniel Vetter
2020-04-15  9:45   ` Sam Ravnborg
2020-04-15  9:45     ` [Intel-gfx] " Sam Ravnborg
2020-04-15 12:02     ` Alexey Brodkin
2020-04-15 12:02       ` [Intel-gfx] " Alexey Brodkin
2020-04-15 12:20       ` Daniel Vetter
2020-04-15 12:20         ` [Intel-gfx] " Daniel Vetter
2020-04-28 14:08         ` Daniel Vetter
2020-04-28 14:08           ` [Intel-gfx] " Daniel Vetter
2020-05-08 13:56           ` Alexey Brodkin
2020-05-08 13:56             ` [Intel-gfx] " Alexey Brodkin
2020-05-08 18:07             ` Daniel Vetter
2020-05-08 18:07               ` [Intel-gfx] " Daniel Vetter
2020-06-04  8:05               ` Daniel Vetter
2020-06-04  8:05                 ` [Intel-gfx] " Daniel Vetter
2020-06-04 10:38                 ` Eugeniy Paltsev
2020-06-04 10:38                   ` [Intel-gfx] " Eugeniy Paltsev
2020-06-04 11:19                   ` Daniel Vetter
2020-06-04 11:19                     ` [Intel-gfx] " Daniel Vetter
2020-06-04 19:00                     ` Eugeniy Paltsev
2020-06-04 19:00                       ` [Intel-gfx] " Eugeniy Paltsev
2020-06-05 19:55                       ` Daniel Vetter
2020-06-05 19:55                         ` [Intel-gfx] " Daniel Vetter
2020-06-09 12:08                         ` Eugeniy Paltsev
2020-06-09 12:08                           ` [Intel-gfx] " Eugeniy Paltsev
2020-06-09 13:02                           ` Daniel Vetter
2020-06-09 13:02                             ` [Intel-gfx] " Daniel Vetter
2020-07-17  9:04                             ` Daniel Vetter
2020-07-17  9:04                               ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 54/59] drm/aspeed: Drop aspeed_gfx->fbdev Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-24 18:00   ` Sam Ravnborg
2020-04-24 18:00     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 18:00     ` Sam Ravnborg
2020-04-15  7:40 ` [PATCH 55/59] drm/aspeed: Use devm_drm_dev_alloc Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-24 18:02   ` Sam Ravnborg
2020-04-24 18:02     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 18:02     ` Sam Ravnborg
2020-04-15  7:40 ` [PATCH 56/59] drm/aspeed: Use managed drmm_mode_config_cleanup Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-24 18:10   ` Sam Ravnborg
2020-04-24 18:10     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 18:10     ` Sam Ravnborg
2020-04-28 14:12     ` Daniel Vetter
2020-04-28 14:12       ` [Intel-gfx] " Daniel Vetter
2020-04-28 14:12       ` Daniel Vetter
2020-04-28 17:03       ` Sam Ravnborg
2020-04-28 17:03         ` [Intel-gfx] " Sam Ravnborg
2020-04-28 17:03         ` Sam Ravnborg
2020-04-15  7:40 ` [PATCH 57/59] drm/ast: Use managed pci functions Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:52   ` Thomas Zimmermann
2020-04-15  7:52     ` [Intel-gfx] " Thomas Zimmermann
2020-04-15  8:09     ` Daniel Vetter
2020-04-15  8:09       ` [Intel-gfx] " Daniel Vetter
2020-04-15  8:17       ` Daniel Vetter
2020-04-15  8:17         ` [Intel-gfx] " Daniel Vetter
2020-04-15 12:23         ` Daniel Vetter
2020-04-15 12:23           ` [Intel-gfx] " Daniel Vetter
2020-06-11 12:04   ` Thomas Zimmermann
2020-06-11 12:04     ` [Intel-gfx] " Thomas Zimmermann
2020-06-16 11:55     ` Daniel Vetter
2020-06-16 11:55       ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40 ` [PATCH 58/59] drm/ast: Drop explicit connector register/unregister Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:53   ` Thomas Zimmermann
2020-04-15  7:53     ` [Intel-gfx] " Thomas Zimmermann
2020-04-24 18:11   ` Sam Ravnborg
2020-04-24 18:11     ` [Intel-gfx] " Sam Ravnborg
2020-04-15  7:40 ` [PATCH 59/59] drm/bochs: Remove explicit drm_connector_register Daniel Vetter
2020-04-15  7:40   ` [Intel-gfx] " Daniel Vetter
2020-04-15  7:40   ` Daniel Vetter
2020-04-21  7:39   ` Gerd Hoffmann
2020-04-21  7:39     ` [Intel-gfx] " Gerd Hoffmann
2020-04-21  7:39     ` Gerd Hoffmann
2020-04-24 18:11   ` Sam Ravnborg
2020-04-24 18:11     ` [Intel-gfx] " Sam Ravnborg
2020-04-24 18:11     ` Sam Ravnborg
2020-04-15  8:04 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for devm_drm_dev_alloc, v2 Patchwork
2020-04-15  8:23 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2020-04-15  8:26 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-04-15 23:45 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-06-04 11:58 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for devm_drm_dev_alloc, v2 (rev2) Patchwork
2020-06-04 19:36 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for devm_drm_dev_alloc, v2 (rev3) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKMK7uH2vhrQ7eTTF1B+==UJS9ZxhDv2RDvR0ct4P0vVJobf=w@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=sam@ravnborg.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.