All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-rockchip@lists.infradead.org,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	linux-arm-kernel@lists.infradead.org,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 4/8] drm/rockchip: Use drm_gem_fb_create_with_dirty
Date: Wed, 27 Nov 2019 18:33:07 +0100	[thread overview]
Message-ID: <023053cb-9f72-c29a-ec2f-cf7532ff5c43@collabora.com> (raw)
In-Reply-To: <20191115092120.4445-5-daniel.vetter@ffwll.ch>

Hi Daniel,

After applying this patch there are some slight differences
in the effective behavior of the code.

I can't tell if they are important, please see below.

Andrzej

W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
> If rockchip would switch over to the generic fbdev setup we could
> grabage collect even more of all this code (all of the remaining fb
> handling code really).
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sandy Huang <hjc@rock-chips.com>
> Cc: "Heiko Stübner" <heiko@sntech.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-rockchip@lists.infradead.org
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 +---------------------
>   1 file changed, 1 insertion(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index ca01234c037c..081dbdaa0b07 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -53,64 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
>   	return fb;
>   }
>   
> -static struct drm_framebuffer *
> -rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> -			const struct drm_mode_fb_cmd2 *mode_cmd)
> -{
> -	const struct drm_format_info *info = drm_get_format_info(dev,
> -								 mode_cmd);
> -	struct drm_framebuffer *fb;
> -	struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
> -	struct drm_gem_object *obj;
> -	int num_planes = min_t(int, info->num_planes, ROCKCHIP_MAX_FB_BUFFER);
> -	int ret;
> -	int i;
> -
> -	for (i = 0; i < num_planes; i++) {

drm_gem_fb_create_with_funcs(), if no error happens,
iterates exactly info->num_planes times,
but the function being removed here iterates
min_t(int, info->num_planes, 3) times.

Is it ensured earlier elsewhere that info->num_planes does not exceed 3?

> -		unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> -		unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
> -		unsigned int min_size;
> -
> -		obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> -		if (!obj) {
> -			DRM_DEV_ERROR(dev->dev,
> -				      "Failed to lookup GEM object\n");
> -			ret = -ENXIO;
> -			goto err_gem_object_unreference;
> -		}
> -
> -		min_size = (height - 1) * mode_cmd->pitches[i] +
> -			mode_cmd->offsets[i] +
> -			width * info->cpp[i];

This computation in drm_gem_fb_create_with_funcs looks like this:

		min_size = (height - 1) * mode_cmd->pitches[i]
			 + drm_format_info_min_pitch(info, i, width)
			 + mode_cmd->offsets[i];

Perhaps that's actually the same thing?

> -
> -		if (obj->size < min_size) {
> -			drm_gem_object_put_unlocked(obj);
> -			ret = -EINVAL;
> -			goto err_gem_object_unreference;
> -		}
> -		objs[i] = obj;
> -	}
> -
> -	fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
> -	if (IS_ERR(fb)) {
> -		ret = PTR_ERR(fb);
> -		goto err_gem_object_unreference;
> -	}
> -
> -	return fb;
> -
> -err_gem_object_unreference:
> -	for (i--; i >= 0; i--)
> -		drm_gem_object_put_unlocked(objs[i]);
> -	return ERR_PTR(ret);
> -}
> -
>   static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
>   	.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
>   };
>   
>   static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
> -	.fb_create = rockchip_user_fb_create,
> +	.fb_create = drm_gem_fb_create,

That way you leave out the ->dirty() callback from
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs

I'd say instead:

struct drm_framebuffer *
rockchip_gem_fb_create(struct drm_device *dev, struct drm_file *file,
		       const struct drm_mode_fb_cmd2 *mode_cmd)
{
	return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
					    &rockchip_drm_fb_funcs);
}

and then

+	.fb_create = rockchip_gem_fb_create,

>   	.output_poll_changed = drm_fb_helper_output_poll_changed,
>   	.atomic_check = drm_atomic_helper_check,
>   	.atomic_commit = drm_atomic_helper_commit,
> 

_______________________________________________
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: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-rockchip@lists.infradead.org,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	linux-arm-kernel@lists.infradead.org,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 4/8] drm/rockchip: Use drm_gem_fb_create_with_dirty
Date: Wed, 27 Nov 2019 18:33:07 +0100	[thread overview]
Message-ID: <023053cb-9f72-c29a-ec2f-cf7532ff5c43@collabora.com> (raw)
In-Reply-To: <20191115092120.4445-5-daniel.vetter@ffwll.ch>

Hi Daniel,

After applying this patch there are some slight differences
in the effective behavior of the code.

I can't tell if they are important, please see below.

Andrzej

W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
> If rockchip would switch over to the generic fbdev setup we could
> grabage collect even more of all this code (all of the remaining fb
> handling code really).
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sandy Huang <hjc@rock-chips.com>
> Cc: "Heiko Stübner" <heiko@sntech.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-rockchip@lists.infradead.org
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 +---------------------
>   1 file changed, 1 insertion(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index ca01234c037c..081dbdaa0b07 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -53,64 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
>   	return fb;
>   }
>   
> -static struct drm_framebuffer *
> -rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> -			const struct drm_mode_fb_cmd2 *mode_cmd)
> -{
> -	const struct drm_format_info *info = drm_get_format_info(dev,
> -								 mode_cmd);
> -	struct drm_framebuffer *fb;
> -	struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
> -	struct drm_gem_object *obj;
> -	int num_planes = min_t(int, info->num_planes, ROCKCHIP_MAX_FB_BUFFER);
> -	int ret;
> -	int i;
> -
> -	for (i = 0; i < num_planes; i++) {

drm_gem_fb_create_with_funcs(), if no error happens,
iterates exactly info->num_planes times,
but the function being removed here iterates
min_t(int, info->num_planes, 3) times.

Is it ensured earlier elsewhere that info->num_planes does not exceed 3?

> -		unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> -		unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
> -		unsigned int min_size;
> -
> -		obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> -		if (!obj) {
> -			DRM_DEV_ERROR(dev->dev,
> -				      "Failed to lookup GEM object\n");
> -			ret = -ENXIO;
> -			goto err_gem_object_unreference;
> -		}
> -
> -		min_size = (height - 1) * mode_cmd->pitches[i] +
> -			mode_cmd->offsets[i] +
> -			width * info->cpp[i];

This computation in drm_gem_fb_create_with_funcs looks like this:

		min_size = (height - 1) * mode_cmd->pitches[i]
			 + drm_format_info_min_pitch(info, i, width)
			 + mode_cmd->offsets[i];

Perhaps that's actually the same thing?

> -
> -		if (obj->size < min_size) {
> -			drm_gem_object_put_unlocked(obj);
> -			ret = -EINVAL;
> -			goto err_gem_object_unreference;
> -		}
> -		objs[i] = obj;
> -	}
> -
> -	fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
> -	if (IS_ERR(fb)) {
> -		ret = PTR_ERR(fb);
> -		goto err_gem_object_unreference;
> -	}
> -
> -	return fb;
> -
> -err_gem_object_unreference:
> -	for (i--; i >= 0; i--)
> -		drm_gem_object_put_unlocked(objs[i]);
> -	return ERR_PTR(ret);
> -}
> -
>   static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
>   	.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
>   };
>   
>   static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
> -	.fb_create = rockchip_user_fb_create,
> +	.fb_create = drm_gem_fb_create,

That way you leave out the ->dirty() callback from
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs

I'd say instead:

struct drm_framebuffer *
rockchip_gem_fb_create(struct drm_device *dev, struct drm_file *file,
		       const struct drm_mode_fb_cmd2 *mode_cmd)
{
	return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
					    &rockchip_drm_fb_funcs);
}

and then

+	.fb_create = rockchip_gem_fb_create,

>   	.output_poll_changed = drm_fb_helper_output_poll_changed,
>   	.atomic_check = drm_atomic_helper_check,
>   	.atomic_commit = drm_atomic_helper_commit,
> 


_______________________________________________
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: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: linux-rockchip@lists.infradead.org,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	linux-arm-kernel@lists.infradead.org,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [Intel-gfx] [PATCH 4/8] drm/rockchip: Use drm_gem_fb_create_with_dirty
Date: Wed, 27 Nov 2019 18:33:07 +0100	[thread overview]
Message-ID: <023053cb-9f72-c29a-ec2f-cf7532ff5c43@collabora.com> (raw)
Message-ID: <20191127173307.Ev5cAsIhC3r3t4U4LNajAK3GfwUlzl39jd2IAgkRqXQ@z> (raw)
In-Reply-To: <20191115092120.4445-5-daniel.vetter@ffwll.ch>

Hi Daniel,

After applying this patch there are some slight differences
in the effective behavior of the code.

I can't tell if they are important, please see below.

Andrzej

W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
> If rockchip would switch over to the generic fbdev setup we could
> grabage collect even more of all this code (all of the remaining fb
> handling code really).
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sandy Huang <hjc@rock-chips.com>
> Cc: "Heiko Stübner" <heiko@sntech.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-rockchip@lists.infradead.org
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 +---------------------
>   1 file changed, 1 insertion(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index ca01234c037c..081dbdaa0b07 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -53,64 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
>   	return fb;
>   }
>   
> -static struct drm_framebuffer *
> -rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> -			const struct drm_mode_fb_cmd2 *mode_cmd)
> -{
> -	const struct drm_format_info *info = drm_get_format_info(dev,
> -								 mode_cmd);
> -	struct drm_framebuffer *fb;
> -	struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
> -	struct drm_gem_object *obj;
> -	int num_planes = min_t(int, info->num_planes, ROCKCHIP_MAX_FB_BUFFER);
> -	int ret;
> -	int i;
> -
> -	for (i = 0; i < num_planes; i++) {

drm_gem_fb_create_with_funcs(), if no error happens,
iterates exactly info->num_planes times,
but the function being removed here iterates
min_t(int, info->num_planes, 3) times.

Is it ensured earlier elsewhere that info->num_planes does not exceed 3?

> -		unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> -		unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
> -		unsigned int min_size;
> -
> -		obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> -		if (!obj) {
> -			DRM_DEV_ERROR(dev->dev,
> -				      "Failed to lookup GEM object\n");
> -			ret = -ENXIO;
> -			goto err_gem_object_unreference;
> -		}
> -
> -		min_size = (height - 1) * mode_cmd->pitches[i] +
> -			mode_cmd->offsets[i] +
> -			width * info->cpp[i];

This computation in drm_gem_fb_create_with_funcs looks like this:

		min_size = (height - 1) * mode_cmd->pitches[i]
			 + drm_format_info_min_pitch(info, i, width)
			 + mode_cmd->offsets[i];

Perhaps that's actually the same thing?

> -
> -		if (obj->size < min_size) {
> -			drm_gem_object_put_unlocked(obj);
> -			ret = -EINVAL;
> -			goto err_gem_object_unreference;
> -		}
> -		objs[i] = obj;
> -	}
> -
> -	fb = rockchip_fb_alloc(dev, mode_cmd, objs, i);
> -	if (IS_ERR(fb)) {
> -		ret = PTR_ERR(fb);
> -		goto err_gem_object_unreference;
> -	}
> -
> -	return fb;
> -
> -err_gem_object_unreference:
> -	for (i--; i >= 0; i--)
> -		drm_gem_object_put_unlocked(objs[i]);
> -	return ERR_PTR(ret);
> -}
> -
>   static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
>   	.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
>   };
>   
>   static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
> -	.fb_create = rockchip_user_fb_create,
> +	.fb_create = drm_gem_fb_create,

That way you leave out the ->dirty() callback from
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs

I'd say instead:

struct drm_framebuffer *
rockchip_gem_fb_create(struct drm_device *dev, struct drm_file *file,
		       const struct drm_mode_fb_cmd2 *mode_cmd)
{
	return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
					    &rockchip_drm_fb_funcs);
}

and then

+	.fb_create = rockchip_gem_fb_create,

>   	.output_poll_changed = drm_fb_helper_output_poll_changed,
>   	.atomic_check = drm_atomic_helper_check,
>   	.atomic_commit = drm_atomic_helper_commit,
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-11-27 17:33 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15  9:21 [PATCH 0/8] fb_create drive-through cleanups Daniel Vetter
2019-11-15  9:21 ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21 ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 1/8] drm/fb: More paranoia in addfb checks Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15 10:49   ` Pekka Paalanen
2019-11-15 10:49     ` [Intel-gfx] " Pekka Paalanen
2019-11-15 12:44   ` Ville Syrjälä
2019-11-15 12:44     ` Ville Syrjälä
2019-11-15 15:26     ` Daniel Vetter
2019-11-15 15:26       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 2/8] drm/atmel: ditch fb_create wrapper Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:33   ` Boris Brezillon
2019-11-15  9:33     ` [Intel-gfx] " Boris Brezillon
2019-11-15  9:33     ` Boris Brezillon
2019-11-19 21:22     ` Daniel Vetter
2019-11-19 21:22       ` [Intel-gfx] " Daniel Vetter
2019-11-19 21:22       ` Daniel Vetter
2019-11-23  8:49       ` Sam Ravnborg
2019-11-23  8:49         ` [Intel-gfx] " Sam Ravnborg
2019-11-23  8:49         ` Sam Ravnborg
2019-11-23  8:49         ` Sam Ravnborg
2019-11-15  9:21 ` [PATCH 3/8] drm/mediatek: don't open-code drm_gem_fb_create Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-22  7:42   ` CK Hu
2019-11-22  7:42     ` [Intel-gfx] " CK Hu
2019-11-22  7:42     ` CK Hu
2019-11-22  7:42     ` CK Hu
2019-11-22 17:09     ` Daniel Vetter
2019-11-22 17:09       ` [Intel-gfx] " Daniel Vetter
2019-11-22 17:09       ` Daniel Vetter
2019-11-22 17:09       ` Daniel Vetter
2019-11-22 17:09       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 4/8] drm/rockchip: Use drm_gem_fb_create_with_dirty Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-27 11:45   ` Andrzej Pietrasiewicz
2019-11-27 11:45     ` [Intel-gfx] " Andrzej Pietrasiewicz
2019-11-27 11:45     ` Andrzej Pietrasiewicz
2019-11-27 11:45     ` Andrzej Pietrasiewicz
2019-11-27 17:33   ` Andrzej Pietrasiewicz [this message]
2019-11-27 17:33     ` [Intel-gfx] " Andrzej Pietrasiewicz
2019-11-27 17:33     ` Andrzej Pietrasiewicz
2019-11-27 17:54     ` Daniel Vetter
2019-11-27 17:54       ` [Intel-gfx] " Daniel Vetter
2019-11-27 17:54       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 5/8] drm/tilcdc: Drop drm_gem_fb_create wrapper Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15 13:21   ` Jyri Sarha
2019-11-15 13:21     ` [Intel-gfx] " Jyri Sarha
2019-11-15 13:21     ` Jyri Sarha
2019-11-19 21:25     ` Daniel Vetter
2019-11-19 21:25       ` [Intel-gfx] " Daniel Vetter
2019-11-19 21:25       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 6/8] drm/xen: Simplify fb_create Daniel Vetter
2019-11-15  9:21   ` [Xen-devel] " Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15 10:33   ` Oleksandr Andrushchenko
2019-11-15 10:33     ` [Xen-devel] " Oleksandr Andrushchenko
2019-11-15 10:33     ` [Intel-gfx] " Oleksandr Andrushchenko
2019-11-15 10:33     ` Oleksandr Andrushchenko
2019-11-19 21:25     ` Daniel Vetter
2019-11-19 21:25       ` [Xen-devel] " Daniel Vetter
2019-11-19 21:25       ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21 ` [PATCH 7/8] drm/hibmc: Use drm_gem_fb_create Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-22  8:09   ` Thomas Zimmermann
2019-11-22  8:09     ` [Intel-gfx] " Thomas Zimmermann
2019-11-22  8:16   ` Thomas Zimmermann
2019-11-22  8:16     ` [Intel-gfx] " Thomas Zimmermann
2019-11-22  9:12     ` Daniel Vetter
2019-11-22  9:12       ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21 ` [PATCH 8/8] drm/todo: Add entry for fb funcs related cleanups Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-20 10:46   ` Daniel Vetter
2019-11-20 10:46     ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:30 ` ✗ Fi.CI.CHECKPATCH: warning for fb_create drive-through cleanups Patchwork
2019-11-15  9:30   ` [Intel-gfx] " Patchwork
2019-11-15  9:50 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-11-15  9:50   ` [Intel-gfx] " 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=023053cb-9f72-c29a-ec2f-cf7532ff5c43@collabora.com \
    --to=andrzej.p@collabora.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.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.