From: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
To: Thomas Zimmermann <tzimmermann-l3A5Bk7waGM@public.gmane.org>,
Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Alexandre Belloni
<alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>,
David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
Jose Roberto de Souza
<jose.souza-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-stm32-XDFAJ8BFU24N7RejjzZ/Li2xQDfSxrLKVpNB7YpNyf8@public.gmane.org,
Emil Velikov
<emil.velikov-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Ludovic Desroches
<ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>,
NXP Linux Team <linux-imx-3arQi8VN3Tc@public.gmane.org>,
Dave Airlie <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Boris Brezillon
<bbrezillon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Nicolas Ferre
<nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>,
Andrzej
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
David Airlie <airlied@linux.ie>,
Jose Roberto de Souza <jose.souza@intel.com>,
virtualization@lists.linux-foundation.org,
Gerd Hoffmann <kraxel@redhat.com>,
linux-stm32@st-md-mailman.stormreply.com,
Emil Velikov <emil.velikov@collabora.com>,
linux-samsung-soc@vger.kernel.org, amd-gfx@lists.freedesktop.org,
linux-rockchip@lists.infradead.org,
Ludovic Desroches <ludovic.desroches@microchip.com>,
NXP Linux Team <linux-imx@nxp.com>,
Dave Airlie <airlied@redhat.com>,
linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,
linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Boris Brezillon <bbrezillon@kernel.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam@ravnborg.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-samsung-soc@vger.kernel.org,
Boris Brezillon <bbrezillon@kernel.org>,
David Airlie <airlied@linux.ie>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
NXP Linux Team <linux-imx@nxp.com>,
Jose Roberto de Souza <jose.souza@intel.com>,
virtualization@lists.linux-foundation.org,
linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org,
Ludovic Desroches <ludovic.desroches@microchip.com>,
linux-mediatek@lists.infradead.org,
Gerd Hoffmann <kraxel@redhat.com>,
linux-amlogic@lists.infradead.org, linux-tegra@vger.kernel.org,
Dave Airlie <airlied@redhat.com>,
amd-gfx@lists.freedesktop.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
Emil Velikov <emil.velikov@collabora.com>
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam@ravnborg.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-samsung-soc@vger.kernel.org,
Boris Brezillon <bbrezillon@kernel.org>,
David Airlie <airlied@linux.ie>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
NXP Linux Team <linux-imx@nxp.com>,
Jose Roberto de Souza <jose.souza@intel.com>,
virtualization@lists.linux-foundation.org,
linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org,
Ludovic Desroches <ludovic.desroches@microchip.com>,
linux-mediatek@lists.infradead.org,
Gerd Hoffmann <kraxel@redhat.com>,
linux-amlogic@lists.infradead.org, linux-tegra@vger.kernel.org,
Dave Airlie <airlied@redhat.com>,
amd-gfx@lists.freedesktop.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
Emil Velikov <emil.velikov@collabora.com>
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam@ravnborg.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-samsung-soc@vger.kernel.org,
Boris Brezillon <bbrezillon@kernel.org>,
David Airlie <airlied@linux.ie>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
NXP Linux Team <linux-imx@nxp.com>,
Jose Roberto de Souza <jose.souza@intel.com>,
virtualization@lists.linux-foundation.org,
linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org,
Ludovic Desroches <ludovic.desroches@microchip.com>,
linux-mediatek@lists.infradead.org,
Gerd Hoffmann <kraxel@redhat.com>,
linux-amlogic@lists.infradead.org, linux-tegra@vger.kernel.org,
Dave Airlie <airlied@redhat.com>,
amd-gfx@lists.freedesktop.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
Emil Velikov <emil.velikov@collabora.com>
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam@ravnborg.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
_______________________________________________
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: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-samsung-soc@vger.kernel.org,
Boris Brezillon <bbrezillon@kernel.org>,
David Airlie <airlied@linux.ie>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
NXP Linux Team <linux-imx@nxp.com>,
Jose Roberto de Souza <jose.souza@intel.com>,
virtualization@lists.linux-foundation.org,
linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org,
Ludovic Desroches <ludovic.desroches@microchip.com>,
linux-mediatek@lists.infradead.org,
Gerd Hoffmann <kraxel@redhat.com>,
linux-amlogic@lists.infradead.org, linux-tegra@vger.kernel.org,
Dave Airlie <airlied@redhat.com>,
amd-gfx@lists.freedesktop.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
Emil Velikov <emil.velikov@collabora.com>
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam@ravnborg.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-samsung-soc@vger.kernel.org,
Boris Brezillon <bbrezillon@kernel.org>,
David Airlie <airlied@linux.ie>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
NXP Linux Team <linux-imx@nxp.com>,
Jose Roberto de Souza <jose.souza@intel.com>,
virtualization@lists.linux-foundation.org,
linux-renesas-soc@vger.kernel.org,
linux-rockchip@lists.infradead.org,
Ludovic Desroches <ludovic.desroches@microchip.com>,
linux-mediatek@lists.infradead.org,
Gerd Hoffmann <kraxel@redhat.com>,
linux-amlogic@lists.infradead.org, linux-tegra@vger.kernel.org,
Dave Airlie <airlied@redhat.com>,
amd-gfx@lists.freedesktop.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
Emil Velikov <emil.velikov@collabora.com>
Subject: Re: [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Date: Thu, 19 Mar 2020 15:19:54 +0100 [thread overview]
Message-ID: <20200319141954.GA25036@ravnborg.org> (raw)
In-Reply-To: <20200313201744.19773-1-sam@ravnborg.org>
On Fri, Mar 13, 2020 at 09:17:41PM +0100, Sam Ravnborg wrote:
> Thomas Zimmermann had made a nice patch-set that introduced
> drm_simple_encoder_init() which is already present in drm-misc-next.
>
> While looking at this it was suddenly obvious to me that
> this was functionalty that really should be included in drm_encoder.c
> The case where the core could handle the callback is pretty
> common and not part of the simple pipe line.
>
> So after some dialog on dri-devel the conclusion was to go for
> a change like this:
>
> drm_encoder_init_funcs() for all users that specified a
> drm_encoder_funcs to extend the functionality.
>
> drm_encoder_init() for all users that did not
> need to extend the basic functionality with
> drm_encoder_funcs.
>
> A similar approach with a _funcs() prefix is used elsewhere in drm/
>
> This required a rename of the existing users, and
> a follow-up patch that moves drm_simple_encoder_init()
> to drm_encoder.c
>
> Patches 3 in this set demonstrate the use of drm_encoder_init().
> There are many more drivers that can be converted as Thomas
> has already demonstrated.
>
> This is all based on work done by Thomas Zimmermann,
> I just wanted to implement my suggestion so
> we could select the best way forward.
>
> Note: Daniel Vetter has hinted the approach implemented
> here smelled like middle-layer.
> IMO this is not so, it is just a way to handle cleanup
> for the simple cases.
We discussed this patch-set briefly on irc.
With the upcoming drmm_ changes and such this is bad timing..
And in the end this may be pointless code-chrunch.
Patch-set shelfed for now - may re-visit it later.
Sam
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2020-03-19 14:19 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 20:17 [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs() Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` [PATCH v1 3/3] drm/atmel-hlcdc: Use drm_encoder_init() Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
[not found] ` <20200313201744.19773-1-sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
2020-03-13 20:17 ` [PATCH v1 1/3] drm: drm_encoder_init() => drm_encoder_init_funcs() Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` [PATCH v1 2/3] drm: drm_simple_encoder_init() => drm_encoder_init() Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-13 20:17 ` Sam Ravnborg
2020-03-19 14:19 ` Sam Ravnborg [this message]
2020-03-19 14:19 ` [PATCH v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs() Sam Ravnborg
2020-03-19 14:19 ` Sam Ravnborg
2020-03-19 14:19 ` Sam Ravnborg
2020-03-19 14:19 ` Sam Ravnborg
2020-03-19 14:19 ` Sam Ravnborg
2020-03-19 14:19 ` Sam Ravnborg
[not found] ` <20200319141954.GA25036-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
2020-03-19 17:05 ` Sam Ravnborg
2020-03-19 17:05 ` Sam Ravnborg
2020-03-19 17:05 ` Sam Ravnborg
2020-03-19 17:05 ` Sam Ravnborg
2020-03-19 17:05 ` Sam Ravnborg
2020-03-19 17:05 ` Sam Ravnborg
2020-03-19 17:05 ` Sam Ravnborg
2020-03-24 8:33 ` Thomas Zimmermann
2020-03-24 8:33 ` Thomas Zimmermann
2020-03-24 8:33 ` Thomas Zimmermann
2020-03-24 8:33 ` Thomas Zimmermann
2020-03-24 8:33 ` Thomas Zimmermann
2020-03-24 8:33 ` Thomas Zimmermann
2020-03-24 8:33 ` Thomas Zimmermann
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=20200319141954.GA25036@ravnborg.org \
--to=sam-uyr5n9q2vtjg9huczpvpmw@public.gmane.org \
--cc=airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=airlied-cv59FeDIM0c@public.gmane.org \
--cc=alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=bbrezillon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=daniel-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=emil.velikov-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org \
--cc=jose.souza-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-imx-3arQi8VN3Tc@public.gmane.org \
--cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-stm32-XDFAJ8BFU24N7RejjzZ/Li2xQDfSxrLKVpNB7YpNyf8@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org \
--cc=nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org \
--cc=tzimmermann-l3A5Bk7waGM@public.gmane.org \
--cc=virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
/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.