All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	airlied@gmail.com, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org
Cc: linux-samsung-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()
Date: Wed, 25 Jan 2023 15:11:43 +0100	[thread overview]
Message-ID: <511111fe-f228-b902-927e-271977b05201@suse.de> (raw)
In-Reply-To: <2a007c84-1dd6-ed8a-39ac-8c7c070513f3@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3600 bytes --]

Hi

Am 25.01.23 um 10:18 schrieb Javier Martinez Canillas:
> On 1/24/23 14:40, Thomas Zimmermann wrote:
>> Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
>> functional changes.
>>
>> v2:
>> 	* declare as static inline (kernel test robot)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 14 +++++++++++++-
>>   include/drm/drm_fb_helper.h     |  5 +++++
>>   2 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index c5c13e192b64..4379bcd7718b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -435,6 +435,18 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   }
>>   EXPORT_SYMBOL(drm_fb_helper_prepare);
>>   
>> +/**
>> + * drm_fb_helper_unprepare - clean up a drm_fb_helper structure
>> + * @fb_helper: driver-allocated fbdev helper structure to set up
>> + *
>> + * Cleans up the framebuffer helper. Inverse of drm_fb_helper_prepare().
>> + */
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +	mutex_destroy(&fb_helper->lock);
>> +}
> 
> I like that we have an _unprepare that is the inverse of the _prepare, but
> since is only destroying the mutex, maybe is an unneeded indirection level?
> 
> Or do you plan to add more cleanup to that _unprepare function? Otherwise I
> would just make it an inline function.

There could possibly be more; not sure yet. With patch 04, the call is 
being invoked from drm_fbdev_generic.c. And I have prototype patches 
that convert a number of driver-internal fbdevs to use struct 
drm_client. They all follow the same design/structure/pattern that is 
being layed out in generic-fbdev in this patchset. In the end 
drm_fb_helper_unprepare will definitely be a public interface of the 
fbdev helpers.

Best regards
Thomas

> 
>> +EXPORT_SYMBOL(drm_fb_helper_unprepare);
>> +
> 
> Does it have to be an exported symbol? AFAICT the only user for now is the
> drm_fb_helper_fini() function, so the function could be a static inline.
> 
> [...]
> 
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index f443e1f11654..39710c570a04 100644
>> --- a/include/drm/drm_fb_helper.h
>> +++ b/include/drm/drm_fb_helper.h
>> @@ -230,6 +230,7 @@ drm_fb_helper_from_client(struct drm_client_dev *client)
>>   #ifdef CONFIG_DRM_FBDEV_EMULATION
>>   void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   			   const struct drm_fb_helper_funcs *funcs);
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper);
>>   int drm_fb_helper_init(struct drm_device *dev, struct drm_fb_helper *helper);
>>   void drm_fb_helper_fini(struct drm_fb_helper *helper);
>>   int drm_fb_helper_blank(int blank, struct fb_info *info);
>> @@ -296,6 +297,10 @@ static inline void drm_fb_helper_prepare(struct drm_device *dev,
>>   {
>>   }
>>   
>> +static inline void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +}
>> +
> 
> And you should be able to remove this stub if you limit the scope of the helper.
> 
> No strong opinion though. So if you prefer to keep it as is, feel free to add:
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	airlied@gmail.com, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org
Cc: linux-samsung-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()
Date: Wed, 25 Jan 2023 15:11:43 +0100	[thread overview]
Message-ID: <511111fe-f228-b902-927e-271977b05201@suse.de> (raw)
In-Reply-To: <2a007c84-1dd6-ed8a-39ac-8c7c070513f3@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3600 bytes --]

Hi

Am 25.01.23 um 10:18 schrieb Javier Martinez Canillas:
> On 1/24/23 14:40, Thomas Zimmermann wrote:
>> Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
>> functional changes.
>>
>> v2:
>> 	* declare as static inline (kernel test robot)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 14 +++++++++++++-
>>   include/drm/drm_fb_helper.h     |  5 +++++
>>   2 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index c5c13e192b64..4379bcd7718b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -435,6 +435,18 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   }
>>   EXPORT_SYMBOL(drm_fb_helper_prepare);
>>   
>> +/**
>> + * drm_fb_helper_unprepare - clean up a drm_fb_helper structure
>> + * @fb_helper: driver-allocated fbdev helper structure to set up
>> + *
>> + * Cleans up the framebuffer helper. Inverse of drm_fb_helper_prepare().
>> + */
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +	mutex_destroy(&fb_helper->lock);
>> +}
> 
> I like that we have an _unprepare that is the inverse of the _prepare, but
> since is only destroying the mutex, maybe is an unneeded indirection level?
> 
> Or do you plan to add more cleanup to that _unprepare function? Otherwise I
> would just make it an inline function.

There could possibly be more; not sure yet. With patch 04, the call is 
being invoked from drm_fbdev_generic.c. And I have prototype patches 
that convert a number of driver-internal fbdevs to use struct 
drm_client. They all follow the same design/structure/pattern that is 
being layed out in generic-fbdev in this patchset. In the end 
drm_fb_helper_unprepare will definitely be a public interface of the 
fbdev helpers.

Best regards
Thomas

> 
>> +EXPORT_SYMBOL(drm_fb_helper_unprepare);
>> +
> 
> Does it have to be an exported symbol? AFAICT the only user for now is the
> drm_fb_helper_fini() function, so the function could be a static inline.
> 
> [...]
> 
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index f443e1f11654..39710c570a04 100644
>> --- a/include/drm/drm_fb_helper.h
>> +++ b/include/drm/drm_fb_helper.h
>> @@ -230,6 +230,7 @@ drm_fb_helper_from_client(struct drm_client_dev *client)
>>   #ifdef CONFIG_DRM_FBDEV_EMULATION
>>   void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   			   const struct drm_fb_helper_funcs *funcs);
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper);
>>   int drm_fb_helper_init(struct drm_device *dev, struct drm_fb_helper *helper);
>>   void drm_fb_helper_fini(struct drm_fb_helper *helper);
>>   int drm_fb_helper_blank(int blank, struct fb_info *info);
>> @@ -296,6 +297,10 @@ static inline void drm_fb_helper_prepare(struct drm_device *dev,
>>   {
>>   }
>>   
>> +static inline void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +}
>> +
> 
> And you should be able to remove this stub if you limit the scope of the helper.
> 
> No strong opinion though. So if you prefer to keep it as is, feel free to add:
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	airlied@gmail.com, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org
Cc: linux-samsung-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()
Date: Wed, 25 Jan 2023 15:11:43 +0100	[thread overview]
Message-ID: <511111fe-f228-b902-927e-271977b05201@suse.de> (raw)
In-Reply-To: <2a007c84-1dd6-ed8a-39ac-8c7c070513f3@redhat.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 3600 bytes --]

Hi

Am 25.01.23 um 10:18 schrieb Javier Martinez Canillas:
> On 1/24/23 14:40, Thomas Zimmermann wrote:
>> Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
>> functional changes.
>>
>> v2:
>> 	* declare as static inline (kernel test robot)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 14 +++++++++++++-
>>   include/drm/drm_fb_helper.h     |  5 +++++
>>   2 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index c5c13e192b64..4379bcd7718b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -435,6 +435,18 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   }
>>   EXPORT_SYMBOL(drm_fb_helper_prepare);
>>   
>> +/**
>> + * drm_fb_helper_unprepare - clean up a drm_fb_helper structure
>> + * @fb_helper: driver-allocated fbdev helper structure to set up
>> + *
>> + * Cleans up the framebuffer helper. Inverse of drm_fb_helper_prepare().
>> + */
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +	mutex_destroy(&fb_helper->lock);
>> +}
> 
> I like that we have an _unprepare that is the inverse of the _prepare, but
> since is only destroying the mutex, maybe is an unneeded indirection level?
> 
> Or do you plan to add more cleanup to that _unprepare function? Otherwise I
> would just make it an inline function.

There could possibly be more; not sure yet. With patch 04, the call is 
being invoked from drm_fbdev_generic.c. And I have prototype patches 
that convert a number of driver-internal fbdevs to use struct 
drm_client. They all follow the same design/structure/pattern that is 
being layed out in generic-fbdev in this patchset. In the end 
drm_fb_helper_unprepare will definitely be a public interface of the 
fbdev helpers.

Best regards
Thomas

> 
>> +EXPORT_SYMBOL(drm_fb_helper_unprepare);
>> +
> 
> Does it have to be an exported symbol? AFAICT the only user for now is the
> drm_fb_helper_fini() function, so the function could be a static inline.
> 
> [...]
> 
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index f443e1f11654..39710c570a04 100644
>> --- a/include/drm/drm_fb_helper.h
>> +++ b/include/drm/drm_fb_helper.h
>> @@ -230,6 +230,7 @@ drm_fb_helper_from_client(struct drm_client_dev *client)
>>   #ifdef CONFIG_DRM_FBDEV_EMULATION
>>   void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   			   const struct drm_fb_helper_funcs *funcs);
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper);
>>   int drm_fb_helper_init(struct drm_device *dev, struct drm_fb_helper *helper);
>>   void drm_fb_helper_fini(struct drm_fb_helper *helper);
>>   int drm_fb_helper_blank(int blank, struct fb_info *info);
>> @@ -296,6 +297,10 @@ static inline void drm_fb_helper_prepare(struct drm_device *dev,
>>   {
>>   }
>>   
>> +static inline void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +}
>> +
> 
> And you should be able to remove this stub if you limit the scope of the helper.
> 
> No strong opinion though. So if you prefer to keep it as is, feel free to add:
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
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: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
	airlied@gmail.com, daniel@ffwll.ch,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org
Cc: linux-samsung-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Intel-gfx] [PATCH v2 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()
Date: Wed, 25 Jan 2023 15:11:43 +0100	[thread overview]
Message-ID: <511111fe-f228-b902-927e-271977b05201@suse.de> (raw)
In-Reply-To: <2a007c84-1dd6-ed8a-39ac-8c7c070513f3@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3600 bytes --]

Hi

Am 25.01.23 um 10:18 schrieb Javier Martinez Canillas:
> On 1/24/23 14:40, Thomas Zimmermann wrote:
>> Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
>> functional changes.
>>
>> v2:
>> 	* declare as static inline (kernel test robot)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 14 +++++++++++++-
>>   include/drm/drm_fb_helper.h     |  5 +++++
>>   2 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
>> index c5c13e192b64..4379bcd7718b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -435,6 +435,18 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   }
>>   EXPORT_SYMBOL(drm_fb_helper_prepare);
>>   
>> +/**
>> + * drm_fb_helper_unprepare - clean up a drm_fb_helper structure
>> + * @fb_helper: driver-allocated fbdev helper structure to set up
>> + *
>> + * Cleans up the framebuffer helper. Inverse of drm_fb_helper_prepare().
>> + */
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +	mutex_destroy(&fb_helper->lock);
>> +}
> 
> I like that we have an _unprepare that is the inverse of the _prepare, but
> since is only destroying the mutex, maybe is an unneeded indirection level?
> 
> Or do you plan to add more cleanup to that _unprepare function? Otherwise I
> would just make it an inline function.

There could possibly be more; not sure yet. With patch 04, the call is 
being invoked from drm_fbdev_generic.c. And I have prototype patches 
that convert a number of driver-internal fbdevs to use struct 
drm_client. They all follow the same design/structure/pattern that is 
being layed out in generic-fbdev in this patchset. In the end 
drm_fb_helper_unprepare will definitely be a public interface of the 
fbdev helpers.

Best regards
Thomas

> 
>> +EXPORT_SYMBOL(drm_fb_helper_unprepare);
>> +
> 
> Does it have to be an exported symbol? AFAICT the only user for now is the
> drm_fb_helper_fini() function, so the function could be a static inline.
> 
> [...]
> 
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index f443e1f11654..39710c570a04 100644
>> --- a/include/drm/drm_fb_helper.h
>> +++ b/include/drm/drm_fb_helper.h
>> @@ -230,6 +230,7 @@ drm_fb_helper_from_client(struct drm_client_dev *client)
>>   #ifdef CONFIG_DRM_FBDEV_EMULATION
>>   void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper,
>>   			   const struct drm_fb_helper_funcs *funcs);
>> +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper);
>>   int drm_fb_helper_init(struct drm_device *dev, struct drm_fb_helper *helper);
>>   void drm_fb_helper_fini(struct drm_fb_helper *helper);
>>   int drm_fb_helper_blank(int blank, struct fb_info *info);
>> @@ -296,6 +297,10 @@ static inline void drm_fb_helper_prepare(struct drm_device *dev,
>>   {
>>   }
>>   
>> +static inline void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
>> +{
>> +}
>> +
> 
> And you should be able to remove this stub if you limit the scope of the helper.
> 
> No strong opinion though. So if you prefer to keep it as is, feel free to add:
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2023-01-25 14:11 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 13:40 [PATCH v2 00/10] drm/fb-helper: Various cleanups Thomas Zimmermann
2023-01-24 13:40 ` Thomas Zimmermann
2023-01-24 13:40 ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40 ` Thomas Zimmermann
2023-01-24 13:40 ` [PATCH v2 01/10] drm/client: Test for connectors before sending hotplug event Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  8:30   ` Javier Martinez Canillas
2023-01-25  8:30     ` Javier Martinez Canillas
2023-01-25  8:30     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-25  8:30     ` Javier Martinez Canillas
2023-01-25 14:04     ` Thomas Zimmermann
2023-01-25 14:04       ` Thomas Zimmermann
2023-01-25 14:04       ` [Intel-gfx] " Thomas Zimmermann
2023-01-25 14:04       ` Thomas Zimmermann
2023-01-24 13:40 ` [PATCH v2 02/10] drm/client: Add hotplug_failed flag Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:05   ` Javier Martinez Canillas
2023-01-25  9:05     ` Javier Martinez Canillas
2023-01-25  9:05     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-25  9:05     ` Javier Martinez Canillas
2023-01-24 13:40 ` [PATCH v2 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare() Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:18   ` Javier Martinez Canillas
2023-01-25  9:18     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-25  9:18     ` Javier Martinez Canillas
2023-01-25  9:18     ` Javier Martinez Canillas
2023-01-25 14:11     ` Thomas Zimmermann [this message]
2023-01-25 14:11       ` [Intel-gfx] " Thomas Zimmermann
2023-01-25 14:11       ` Thomas Zimmermann
2023-01-25 14:11       ` Thomas Zimmermann
2023-01-24 13:40 ` [PATCH v2 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:25   ` Javier Martinez Canillas
2023-01-25  9:25     ` Javier Martinez Canillas
2023-01-25  9:25     ` Javier Martinez Canillas
2023-01-25  9:25     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-24 13:40 ` [PATCH v2 05/10] drm/fb-helper: Remove preferred_bpp parameter from fbdev internals Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:31   ` Javier Martinez Canillas
2023-01-25  9:31     ` Javier Martinez Canillas
2023-01-25  9:31     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-25  9:31     ` Javier Martinez Canillas
2023-01-24 13:40 ` [PATCH v2 06/10] drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  4:51   ` [Intel-gfx] " kernel test robot
2023-01-25  4:51     ` kernel test robot
2023-01-25  4:51     ` kernel test robot
2023-01-25  9:41   ` Javier Martinez Canillas
2023-01-25  9:41     ` Javier Martinez Canillas
2023-01-25  9:41     ` Javier Martinez Canillas
2023-01-25  9:41     ` Javier Martinez Canillas
2023-01-25 12:12   ` [Intel-gfx] " kernel test robot
2023-01-25 12:12     ` kernel test robot
2023-01-25 12:12     ` kernel test robot
2023-01-24 13:40 ` [PATCH v2 07/10] drm/fbdev-generic: Minimize hotplug error handling Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:44   ` Javier Martinez Canillas
2023-01-25  9:44     ` Javier Martinez Canillas
2023-01-25  9:44     ` Javier Martinez Canillas
2023-01-25  9:44     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-24 13:40 ` [PATCH v2 08/10] drm/fbdev-generic: Minimize client unregistering Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:50   ` Javier Martinez Canillas
2023-01-25  9:50     ` Javier Martinez Canillas
2023-01-25  9:50     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-25  9:50     ` Javier Martinez Canillas
2023-01-24 13:40 ` [PATCH v2 09/10] drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy() Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:52   ` Javier Martinez Canillas
2023-01-25  9:52     ` Javier Martinez Canillas
2023-01-25  9:52     ` Javier Martinez Canillas
2023-01-25  9:52     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-24 13:40 ` [PATCH v2 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info' Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-24 13:40   ` [Intel-gfx] " Thomas Zimmermann
2023-01-24 13:40   ` Thomas Zimmermann
2023-01-25  9:54   ` Javier Martinez Canillas
2023-01-25  9:54     ` Javier Martinez Canillas
2023-01-25  9:54     ` Javier Martinez Canillas
2023-01-25  9:54     ` [Intel-gfx] " Javier Martinez Canillas
2023-01-24 19:42 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/fb-helper: Various cleanups (rev2) 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=511111fe-f228-b902-927e-271977b05201@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.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.