* [Intel-gfx] [PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, James (Qian) Wang,
Daniel Vetter, Mihail Atanassov
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here for both komeda and
malidp.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 -
drivers/gpu/drm/arm/malidp_drv.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index aeda4e5ec4f4..ff45f23f3d56 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -247,7 +247,6 @@ static void komeda_kms_mode_config_init(struct komeda_kms_dev *kms,
config->min_height = 0;
config->max_width = 4096;
config->max_height = 4096;
- config->allow_fb_modifiers = true;
config->funcs = &komeda_mode_config_funcs;
config->helper_private = &komeda_mode_config_helpers;
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index d83c7366b348..de59f3302516 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -403,7 +403,6 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = &malidp_mode_config_funcs;
drm->mode_config.helper_private = &malidp_mode_config_helpers;
- drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 2/8] drm/arm/malidp: Always list modifiers
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Daniel Vetter, stable,
Pekka Paalanen, Liviu Dudau, Brian Starkey, Daniel Vetter
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c
index ddbba67f0283..8c2ab3d653b7 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs malidp_de_plane_helper_funcs = {
.atomic_disable = malidp_de_plane_disable,
};
+static const uint64_t linear_only_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
int malidp_de_planes_init(struct drm_device *drm)
{
struct malidp_drm *malidp = drm->dev_private;
@@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
*/
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
&malidp_de_plane_funcs, formats, n,
- (id == DE_SMART) ? NULL : modifiers, plane_type,
- NULL);
+ (id == DE_SMART) ? linear_only_modifiers : modifiers,
+ plane_type, NULL);
if (ret < 0)
goto cleanup;
--
2.31.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 2/8] drm/arm/malidp: Always list modifiers
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, Daniel Vetter, Intel Graphics Development,
stable, Daniel Vetter
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c
index ddbba67f0283..8c2ab3d653b7 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs malidp_de_plane_helper_funcs = {
.atomic_disable = malidp_de_plane_disable,
};
+static const uint64_t linear_only_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
int malidp_de_planes_init(struct drm_device *drm)
{
struct malidp_drm *malidp = drm->dev_private;
@@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
*/
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
&malidp_de_plane_funcs, formats, n,
- (id == DE_SMART) ? NULL : modifiers, plane_type,
- NULL);
+ (id == DE_SMART) ? linear_only_modifiers : modifiers,
+ plane_type, NULL);
if (ret < 0)
goto cleanup;
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 2/8] drm/arm/malidp: Always list modifiers
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, Daniel Vetter, Intel Graphics Development,
Liviu Dudau, stable, Daniel Vetter
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c
index ddbba67f0283..8c2ab3d653b7 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs malidp_de_plane_helper_funcs = {
.atomic_disable = malidp_de_plane_disable,
};
+static const uint64_t linear_only_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
int malidp_de_planes_init(struct drm_device *drm)
{
struct malidp_drm *malidp = drm->dev_private;
@@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
*/
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
&malidp_de_plane_funcs, formats, n,
- (id == DE_SMART) ? NULL : modifiers, plane_type,
- NULL);
+ (id == DE_SMART) ? linear_only_modifiers : modifiers,
+ plane_type, NULL);
if (ret < 0)
goto cleanup;
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH 2/8] drm/arm/malidp: Always list modifiers
2021-04-27 9:20 ` Daniel Vetter
(?)
@ 2021-04-27 15:41 ` Liviu Dudau
-1 siblings, 0 replies; 50+ messages in thread
From: Liviu Dudau @ 2021-04-27 15:41 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development, stable,
Pekka Paalanen, Brian Starkey, Daniel Vetter
On Tue, Apr 27, 2021 at 11:20:12AM +0200, Daniel Vetter wrote:
> Even when all we support is linear, make that explicit. Otherwise the
> uapi is rather confusing.
:)
>
> Cc: stable@vger.kernel.org
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Brian Starkey <brian.starkey@arm.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c
> index ddbba67f0283..8c2ab3d653b7 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs malidp_de_plane_helper_funcs = {
> .atomic_disable = malidp_de_plane_disable,
> };
>
> +static const uint64_t linear_only_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> int malidp_de_planes_init(struct drm_device *drm)
> {
> struct malidp_drm *malidp = drm->dev_private;
> @@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
> */
> ret = drm_universal_plane_init(drm, &plane->base, crtcs,
> &malidp_de_plane_funcs, formats, n,
> - (id == DE_SMART) ? NULL : modifiers, plane_type,
> - NULL);
> + (id == DE_SMART) ? linear_only_modifiers : modifiers,
> + plane_type, NULL);
>
> if (ret < 0)
> goto cleanup;
> --
> 2.31.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 2/8] drm/arm/malidp: Always list modifiers
@ 2021-04-27 15:41 ` Liviu Dudau
0 siblings, 0 replies; 50+ messages in thread
From: Liviu Dudau @ 2021-04-27 15:41 UTC (permalink / raw)
To: Daniel Vetter
Cc: Pekka Paalanen, Intel Graphics Development, stable,
DRI Development, Daniel Vetter
On Tue, Apr 27, 2021 at 11:20:12AM +0200, Daniel Vetter wrote:
> Even when all we support is linear, make that explicit. Otherwise the
> uapi is rather confusing.
:)
>
> Cc: stable@vger.kernel.org
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Brian Starkey <brian.starkey@arm.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c
> index ddbba67f0283..8c2ab3d653b7 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs malidp_de_plane_helper_funcs = {
> .atomic_disable = malidp_de_plane_disable,
> };
>
> +static const uint64_t linear_only_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> int malidp_de_planes_init(struct drm_device *drm)
> {
> struct malidp_drm *malidp = drm->dev_private;
> @@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
> */
> ret = drm_universal_plane_init(drm, &plane->base, crtcs,
> &malidp_de_plane_funcs, formats, n,
> - (id == DE_SMART) ? NULL : modifiers, plane_type,
> - NULL);
> + (id == DE_SMART) ? linear_only_modifiers : modifiers,
> + plane_type, NULL);
>
> if (ret < 0)
> goto cleanup;
> --
> 2.31.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 2/8] drm/arm/malidp: Always list modifiers
@ 2021-04-27 15:41 ` Liviu Dudau
0 siblings, 0 replies; 50+ messages in thread
From: Liviu Dudau @ 2021-04-27 15:41 UTC (permalink / raw)
To: Daniel Vetter
Cc: Pekka Paalanen, Intel Graphics Development, stable,
DRI Development, Daniel Vetter
On Tue, Apr 27, 2021 at 11:20:12AM +0200, Daniel Vetter wrote:
> Even when all we support is linear, make that explicit. Otherwise the
> uapi is rather confusing.
:)
>
> Cc: stable@vger.kernel.org
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Brian Starkey <brian.starkey@arm.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c
> index ddbba67f0283..8c2ab3d653b7 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -927,6 +927,11 @@ static const struct drm_plane_helper_funcs malidp_de_plane_helper_funcs = {
> .atomic_disable = malidp_de_plane_disable,
> };
>
> +static const uint64_t linear_only_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> int malidp_de_planes_init(struct drm_device *drm)
> {
> struct malidp_drm *malidp = drm->dev_private;
> @@ -990,8 +995,8 @@ int malidp_de_planes_init(struct drm_device *drm)
> */
> ret = drm_universal_plane_init(drm, &plane->base, crtcs,
> &malidp_de_plane_funcs, formats, n,
> - (id == DE_SMART) ? NULL : modifiers, plane_type,
> - NULL);
> + (id == DE_SMART) ? linear_only_modifiers : modifiers,
> + plane_type, NULL);
>
> if (ret < 0)
> goto cleanup;
> --
> 2.31.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH 3/8] drm/i915: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Jani Nikula, Daniel Vetter, Intel Graphics Development,
Karthik B S, José Roberto de Souza, Chris Wilson,
Manasi Navare, Dave Airlie, Daniel Vetter
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 4bbc81d8d649..d2c6959190ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11731,8 +11731,6 @@ static void intel_mode_config_init(struct drm_i915_private *i915)
mode_config->preferred_depth = 24;
mode_config->prefer_shadow = 1;
- mode_config->allow_fb_modifiers = true;
-
mode_config->funcs = &intel_mode_funcs;
mode_config->async_page_flip = has_async_flips(i915);
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 3/8] drm/i915: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Jani Nikula, Daniel Vetter, Intel Graphics Development,
Chris Wilson, Dave Airlie, Daniel Vetter
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 4bbc81d8d649..d2c6959190ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11731,8 +11731,6 @@ static void intel_mode_config_init(struct drm_i915_private *i915)
mode_config->preferred_depth = 24;
mode_config->prefer_shadow = 1;
- mode_config->allow_fb_modifiers = true;
-
mode_config->funcs = &intel_mode_funcs;
mode_config->async_page_flip = has_async_flips(i915);
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 4/8] drm/msm/dpu1: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Rob Clark, Rajendra Nayak, Daniel Vetter,
Intel Graphics Development, Tanmay Shah, Jordan Crouse,
Qinglang Miao, Daniel Vetter, Kalyan Thota
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
v2: Rebase.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Kalyan Thota <kalyant@codeaurora.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Eric Anholt <eric@anholt.net>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Cc: Qinglang Miao <miaoqinglang@huawei.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 88e9cc38c13b..93bc3575bf53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1020,11 +1020,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->catalog->caps->max_mixer_width * 2;
dev->mode_config.max_height = 4096;
- /*
- * Support format modifiers for compression etc.
- */
- dev->mode_config.allow_fb_modifiers = true;
-
dev->max_vblank_count = 0xffffffff;
/* Disable vblank irqs aggressively for power-saving */
dev->vblank_disable_immediate = true;
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 4/8] drm/msm/dpu1: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Rob Clark, Rajendra Nayak, Daniel Vetter,
Intel Graphics Development, Tanmay Shah, Jordan Crouse,
Eric Anholt, Qinglang Miao, Daniel Vetter, Jeykumar Sankaran,
Kalyan Thota
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
v2: Rebase.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Kalyan Thota <kalyant@codeaurora.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Eric Anholt <eric@anholt.net>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Cc: Qinglang Miao <miaoqinglang@huawei.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 88e9cc38c13b..93bc3575bf53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1020,11 +1020,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
dpu_kms->catalog->caps->max_mixer_width * 2;
dev->mode_config.max_height = 4096;
- /*
- * Support format modifiers for compression etc.
- */
- dev->mode_config.allow_fb_modifiers = true;
-
dev->max_vblank_count = 0xffffffff;
/* Disable vblank irqs aggressively for power-saving */
dev->vblank_disable_immediate = true;
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 5/8] drm/msm/mdp4: Fix modifier support enabling
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Daniel Vetter, stable,
Pekka Paalanen, Rob Clark, Jordan Crouse, Emil Velikov,
Sam Ravnborg, Daniel Vetter
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++++++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 3d729270bde1..4a5b518288b0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -88,8 +88,6 @@ static int mdp4_hw_init(struct msm_kms *kms)
if (mdp4_kms->rev > 1)
mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
- dev->mode_config.allow_fb_modifiers = true;
-
out:
pm_runtime_put_sync(dev->dev);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 9aecca919f24..49bdabea8ed5 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -349,6 +349,12 @@ enum mdp4_pipe mdp4_plane_pipe(struct drm_plane *plane)
return mdp4_plane->pipe;
}
+static const uint64_t supported_format_modifiers[] = {
+ DRM_FORMAT_MOD_SAMSUNG_64_32_TILE,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* initialize plane */
struct drm_plane *mdp4_plane_init(struct drm_device *dev,
enum mdp4_pipe pipe_id, bool private_plane)
@@ -377,7 +383,7 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs,
mdp4_plane->formats, mdp4_plane->nformats,
- NULL, type, NULL);
+ supported_format_modifiers, type, NULL);
if (ret)
goto fail;
--
2.31.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 5/8] drm/msm/mdp4: Fix modifier support enabling
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Rob Clark, Pekka Paalanen, Daniel Vetter,
Intel Graphics Development, stable, Jordan Crouse, Daniel Vetter,
Sam Ravnborg, Emil Velikov
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++++++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 3d729270bde1..4a5b518288b0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -88,8 +88,6 @@ static int mdp4_hw_init(struct msm_kms *kms)
if (mdp4_kms->rev > 1)
mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
- dev->mode_config.allow_fb_modifiers = true;
-
out:
pm_runtime_put_sync(dev->dev);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 9aecca919f24..49bdabea8ed5 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -349,6 +349,12 @@ enum mdp4_pipe mdp4_plane_pipe(struct drm_plane *plane)
return mdp4_plane->pipe;
}
+static const uint64_t supported_format_modifiers[] = {
+ DRM_FORMAT_MOD_SAMSUNG_64_32_TILE,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* initialize plane */
struct drm_plane *mdp4_plane_init(struct drm_device *dev,
enum mdp4_pipe pipe_id, bool private_plane)
@@ -377,7 +383,7 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs,
mdp4_plane->formats, mdp4_plane->nformats,
- NULL, type, NULL);
+ supported_format_modifiers, type, NULL);
if (ret)
goto fail;
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 5/8] drm/msm/mdp4: Fix modifier support enabling
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Rob Clark, Pekka Paalanen, Daniel Vetter,
Intel Graphics Development, stable, Jordan Crouse, Daniel Vetter,
Sam Ravnborg, Emil Velikov
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++++++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 3d729270bde1..4a5b518288b0 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -88,8 +88,6 @@ static int mdp4_hw_init(struct msm_kms *kms)
if (mdp4_kms->rev > 1)
mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);
- dev->mode_config.allow_fb_modifiers = true;
-
out:
pm_runtime_put_sync(dev->dev);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 9aecca919f24..49bdabea8ed5 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -349,6 +349,12 @@ enum mdp4_pipe mdp4_plane_pipe(struct drm_plane *plane)
return mdp4_plane->pipe;
}
+static const uint64_t supported_format_modifiers[] = {
+ DRM_FORMAT_MOD_SAMSUNG_64_32_TILE,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* initialize plane */
struct drm_plane *mdp4_plane_init(struct drm_device *dev,
enum mdp4_pipe pipe_id, bool private_plane)
@@ -377,7 +383,7 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs,
mdp4_plane->formats, mdp4_plane->nformats,
- NULL, type, NULL);
+ supported_format_modifiers, type, NULL);
if (ret)
goto fail;
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 6/8] drm/nouveau: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
(?)
(?)
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Daniel Vetter, stable,
Pekka Paalanen, Daniel Vetter, Ben Skeggs, nouveau
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: stable@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index 14101bd2a0ff..929de41c281f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;
- dev->mode_config.allow_fb_modifiers = true;
if (drm->client.device.info.chipset < 0x11)
dev->mode_config.async_page_flip = false;
--
2.31.0
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 6/8] drm/nouveau: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, Daniel Vetter, Intel Graphics Development,
stable, Ben Skeggs, nouveau, Daniel Vetter
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: stable@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index 14101bd2a0ff..929de41c281f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;
- dev->mode_config.allow_fb_modifiers = true;
if (drm->client.device.info.chipset < 0x11)
dev->mode_config.async_page_flip = false;
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 6/8] drm/nouveau: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, Daniel Vetter, Intel Graphics Development,
stable, Ben Skeggs, nouveau, Daniel Vetter
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: stable@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index 14101bd2a0ff..929de41c281f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;
- dev->mode_config.allow_fb_modifiers = true;
if (drm->client.device.info.chipset < 0x11)
dev->mode_config.async_page_flip = false;
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Nouveau] [PATCH 6/8] drm/nouveau: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, Intel Graphics Development, stable, Ben Skeggs,
nouveau, Daniel Vetter
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: stable@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
index 14101bd2a0ff..929de41c281f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -697,7 +697,6 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;
- dev->mode_config.allow_fb_modifiers = true;
if (drm->client.device.info.chipset < 0x11)
dev->mode_config.async_page_flip = false;
--
2.31.0
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, Daniel Vetter, Daniel Vetter,
Yannick Fertre, Philippe Cornu, Benjamin Gaignard,
Maxime Coquelin, Alexandre Torgue, linux-stm32, linux-arm-kernel
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Maxime Coquelin, Daniel Vetter, Intel Graphics Development,
Alexandre Torgue, linux-stm32, Philippe Cornu, Benjamin Gaignard,
Daniel Vetter, Yannick Fertre, linux-arm-kernel
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Maxime Coquelin, Daniel Vetter, Intel Graphics Development,
Alexandre Torgue, linux-stm32, Philippe Cornu, Benjamin Gaignard,
Daniel Vetter, Yannick Fertre, linux-arm-kernel
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* RE: [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` Daniel Vetter
(?)
@ 2021-04-29 19:35 ` Philippe CORNU - foss
-1 siblings, 0 replies; 50+ messages in thread
From: Philippe CORNU - foss @ 2021-04-29 19:35 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, Daniel Vetter, Yannick FERTRE - foss,
Benjamin Gaignard, Maxime Coquelin, Alexandre TORGUE - foss,
linux-stm32, linux-arm-kernel
Hi Daniel,
Many thanks for your patch,
Acked-by: Philippe Cornu <philippe.cornu@st.com>
Philippe :-)
________________________________________
De : Daniel Vetter <daniel.vetter@ffwll.ch>
Envoyé : mardi 27 avril 2021 11:20
À : DRI Development
Cc : Intel Graphics Development; Daniel Vetter; Daniel Vetter; Yannick FERTRE - foss; Philippe CORNU - foss; Benjamin Gaignard; Maxime Coquelin; Alexandre TORGUE - foss; linux-stm32@st-md-mailman.stormreply.com; linux-arm-kernel@lists.infradead.org
Objet : [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
@ 2021-04-29 19:35 ` Philippe CORNU - foss
0 siblings, 0 replies; 50+ messages in thread
From: Philippe CORNU - foss @ 2021-04-29 19:35 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Benjamin Gaignard, Intel Graphics Development,
Alexandre TORGUE - foss, linux-stm32, Maxime Coquelin,
Daniel Vetter, Yannick FERTRE - foss, linux-arm-kernel
Hi Daniel,
Many thanks for your patch,
Acked-by: Philippe Cornu <philippe.cornu@st.com>
Philippe :-)
________________________________________
De : Daniel Vetter <daniel.vetter@ffwll.ch>
Envoyé : mardi 27 avril 2021 11:20
À : DRI Development
Cc : Intel Graphics Development; Daniel Vetter; Daniel Vetter; Yannick FERTRE - foss; Philippe CORNU - foss; Benjamin Gaignard; Maxime Coquelin; Alexandre TORGUE - foss; linux-stm32@st-md-mailman.stormreply.com; linux-arm-kernel@lists.infradead.org
Objet : [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* RE: [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
@ 2021-04-29 19:35 ` Philippe CORNU - foss
0 siblings, 0 replies; 50+ messages in thread
From: Philippe CORNU - foss @ 2021-04-29 19:35 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Benjamin Gaignard, Intel Graphics Development,
Alexandre TORGUE - foss, linux-stm32, Maxime Coquelin,
Daniel Vetter, Yannick FERTRE - foss, linux-arm-kernel
Hi Daniel,
Many thanks for your patch,
Acked-by: Philippe Cornu <philippe.cornu@st.com>
Philippe :-)
________________________________________
De : Daniel Vetter <daniel.vetter@ffwll.ch>
Envoyé : mardi 27 avril 2021 11:20
À : DRI Development
Cc : Intel Graphics Development; Daniel Vetter; Daniel Vetter; Yannick FERTRE - foss; Philippe CORNU - foss; Benjamin Gaignard; Maxime Coquelin; Alexandre TORGUE - foss; linux-stm32@st-md-mailman.stormreply.com; linux-arm-kernel@lists.infradead.org
Objet : [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
- ddev->mode_config.allow_fb_modifiers = true;
-
ret = ltdc_crtc_init(ddev, crtc);
if (ret) {
DRM_ERROR("Failed to init crtc\n");
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-04-27 9:20 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, Maxime Ripard, Thomas Zimmermann,
Daniel Vetter
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none of the planes registered supported
modifiers).
Now that this is all done consistently across all drivers, document
the rules and enforce it in the drm core.
v2:
- Make the capability a link (Simon)
- Note that all is lost before 5.1.
Acked-by: Maxime Ripard <maxime@cerno.tech>
Cc: Simon Ser <contact@emersion.fr>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
include/drm/drm_mode_config.h | 2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0dd43882fe7c..20c7a1665414 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -128,6 +128,13 @@
* pairs supported by this plane. The blob is a struct
* drm_format_modifier_blob. Without this property the plane doesn't
* support buffers with modifiers. Userspace cannot change this property.
+ *
+ * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
+ * capability for general modifier support. If this flag is set then every
+ * plane will have the IN_FORMATS property, even when it only supports
+ * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
+ * various bugs in this area with inconsistencies between the capability
+ * flag and per-plane properties.
*/
static unsigned int drm_num_planes(struct drm_device *dev)
@@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
format_modifier_count++;
}
- if (format_modifier_count)
+ /* autoset the cap and check for consistency across all planes */
+ if (format_modifier_count) {
+ WARN_ON(!config->allow_fb_modifiers &&
+ !list_empty(&config->plane_list));
config->allow_fb_modifiers = true;
+ } else {
+ WARN_ON(config->allow_fb_modifiers);
+ }
plane->modifier_count = format_modifier_count;
plane->modifiers = kmalloc_array(format_modifier_count,
@@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
* drm_universal_plane_init() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.
*
+ * Drivers supporting modifiers must set @format_modifiers on all their planes,
+ * even those that only support DRM_FORMAT_MOD_LINEAR.
+ *
* Returns:
* Zero on success, error code on failure.
*/
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index ab424ddd7665..1ddf7783fdf7 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -909,6 +909,8 @@ struct drm_mode_config {
* @allow_fb_modifiers:
*
* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
+ * Note that drivers should not set this directly, it is automatically
+ * set in drm_universal_plane_init().
*
* IMPORTANT:
*
--
2.31.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-04-27 9:20 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 9:20 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, Maxime Ripard, Maxime Ripard,
Thomas Zimmermann, Simon Ser, Daniel Vetter, Lucas Stach
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none of the planes registered supported
modifiers).
Now that this is all done consistently across all drivers, document
the rules and enforce it in the drm core.
v2:
- Make the capability a link (Simon)
- Note that all is lost before 5.1.
Acked-by: Maxime Ripard <maxime@cerno.tech>
Cc: Simon Ser <contact@emersion.fr>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
include/drm/drm_mode_config.h | 2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0dd43882fe7c..20c7a1665414 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -128,6 +128,13 @@
* pairs supported by this plane. The blob is a struct
* drm_format_modifier_blob. Without this property the plane doesn't
* support buffers with modifiers. Userspace cannot change this property.
+ *
+ * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
+ * capability for general modifier support. If this flag is set then every
+ * plane will have the IN_FORMATS property, even when it only supports
+ * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
+ * various bugs in this area with inconsistencies between the capability
+ * flag and per-plane properties.
*/
static unsigned int drm_num_planes(struct drm_device *dev)
@@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
format_modifier_count++;
}
- if (format_modifier_count)
+ /* autoset the cap and check for consistency across all planes */
+ if (format_modifier_count) {
+ WARN_ON(!config->allow_fb_modifiers &&
+ !list_empty(&config->plane_list));
config->allow_fb_modifiers = true;
+ } else {
+ WARN_ON(config->allow_fb_modifiers);
+ }
plane->modifier_count = format_modifier_count;
plane->modifiers = kmalloc_array(format_modifier_count,
@@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
* drm_universal_plane_init() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.
*
+ * Drivers supporting modifiers must set @format_modifiers on all their planes,
+ * even those that only support DRM_FORMAT_MOD_LINEAR.
+ *
* Returns:
* Zero on success, error code on failure.
*/
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index ab424ddd7665..1ddf7783fdf7 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -909,6 +909,8 @@ struct drm_mode_config {
* @allow_fb_modifiers:
*
* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
+ * Note that drivers should not set this directly, it is automatically
+ * set in drm_universal_plane_init().
*
* IMPORTANT:
*
--
2.31.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-04-27 9:30 ` Simon Ser
-1 siblings, 0 replies; 50+ messages in thread
From: Simon Ser @ 2021-04-27 9:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: Pekka Paalanen, David Airlie, Intel Graphics Development,
DRI Development, Maxime Ripard, Thomas Zimmermann, Daniel Vetter
Reviewed-by: Simon Ser <contact@emersion.fr>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-04-27 11:32 ` Emil Velikov
-1 siblings, 0 replies; 50+ messages in thread
From: Emil Velikov @ 2021-04-27 11:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: Pekka Paalanen, David Airlie, Intel Graphics Development,
DRI Development, Maxime Ripard, Thomas Zimmermann, Daniel Vetter
Hi Daniel,
On Tue, 27 Apr 2021 at 10:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
The comment says "must", yet we have an "if (format_modifiers)" in the codebase.
Shouldn't we add a WARN_ON() + return -EINVAL (or similar) so people
can see and fix their drivers?
As a follow-up one could even go a step further, by erroring out when
the driver hasn't provided valid modifier(s) and even removing
config::allow_fb_modifiers all together.
Although for stable - this series + WARN_ON (no return since it might
break buggy drivers) sounds good.
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
The new note and the existing IMPORTANT are in a weird mix.
Quoting the latter since it doesn't show in the diff.
If this is set the driver must fill out the full implicit modifier
information in their &drm_mode_config_funcs.fb_create hook for legacy
userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
broken for modifier aware userspace.
In particular:
As the new note says "don't set it" and the existing note one says "if
it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
Sadly, nothing comes to mind atm wrt alternative wording.
With the WARN_ON() added or s/must/should/ in the documentation, the series is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
HTH
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-04-27 11:32 ` Emil Velikov
0 siblings, 0 replies; 50+ messages in thread
From: Emil Velikov @ 2021-04-27 11:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: Pekka Paalanen, David Airlie, Intel Graphics Development,
DRI Development, Maxime Ripard, Thomas Zimmermann, Daniel Vetter
Hi Daniel,
On Tue, 27 Apr 2021 at 10:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
The comment says "must", yet we have an "if (format_modifiers)" in the codebase.
Shouldn't we add a WARN_ON() + return -EINVAL (or similar) so people
can see and fix their drivers?
As a follow-up one could even go a step further, by erroring out when
the driver hasn't provided valid modifier(s) and even removing
config::allow_fb_modifiers all together.
Although for stable - this series + WARN_ON (no return since it might
break buggy drivers) sounds good.
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
The new note and the existing IMPORTANT are in a weird mix.
Quoting the latter since it doesn't show in the diff.
If this is set the driver must fill out the full implicit modifier
information in their &drm_mode_config_funcs.fb_create hook for legacy
userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
broken for modifier aware userspace.
In particular:
As the new note says "don't set it" and the existing note one says "if
it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
Sadly, nothing comes to mind atm wrt alternative wording.
With the WARN_ON() added or s/must/should/ in the documentation, the series is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
HTH
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 11:32 ` [Intel-gfx] " Emil Velikov
@ 2021-04-27 12:22 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 12:22 UTC (permalink / raw)
To: Emil Velikov
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter
On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> Hi Daniel,
>
> On Tue, 27 Apr 2021 at 10:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> > * drm_universal_plane_init() to let the DRM managed resource infrastructure
> > * take care of cleanup and deallocation.
> > *
> > + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> > + *
> The comment says "must", yet we have an "if (format_modifiers)" in the codebase.
> Shouldn't we add a WARN_ON() + return -EINVAL (or similar) so people
> can see and fix their drivers?
This is a must only for drivers supporting modifiers, not all drivers.
Hence the check in the if. I did add WARN_ON for the combos that get stuff
wrong though (like only supply one side of the modifier info, not both).
> As a follow-up one could even go a step further, by erroring out when
> the driver hasn't provided valid modifier(s) and even removing
> config::allow_fb_modifiers all together.
Well that currently only exists to avoid walking the plane list (which we
need to do for validation that all planes are the same). It's quite tricky
code for tiny benefit, so I don't think it's worth it trying to remove
allow_fb_modifiers completely.
> Although for stable - this series + WARN_ON (no return since it might
> break buggy drivers) sounds good.
>
> > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > * @allow_fb_modifiers:
> > *
> > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > + * Note that drivers should not set this directly, it is automatically
> > + * set in drm_universal_plane_init().
> > *
> > * IMPORTANT:
> > *
> The new note and the existing IMPORTANT are in a weird mix.
> Quoting the latter since it doesn't show in the diff.
>
> If this is set the driver must fill out the full implicit modifier
> information in their &drm_mode_config_funcs.fb_create hook for legacy
> userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
> broken for modifier aware userspace.
>
> In particular:
> As the new note says "don't set it" and the existing note one says "if
> it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
>
> Sadly, nothing comes to mind atm wrt alternative wording.
Yeah it's a bit disappointing.
> With the WARN_ON() added or s/must/should/ in the documentation, the series is:
With my clarification, can you please recheck whether as-is it's not
correct?
Thanks, Daniel
> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
>
> HTH
> -Emil
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-04-27 12:22 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-04-27 12:22 UTC (permalink / raw)
To: Emil Velikov
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter
On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> Hi Daniel,
>
> On Tue, 27 Apr 2021 at 10:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> > * drm_universal_plane_init() to let the DRM managed resource infrastructure
> > * take care of cleanup and deallocation.
> > *
> > + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> > + *
> The comment says "must", yet we have an "if (format_modifiers)" in the codebase.
> Shouldn't we add a WARN_ON() + return -EINVAL (or similar) so people
> can see and fix their drivers?
This is a must only for drivers supporting modifiers, not all drivers.
Hence the check in the if. I did add WARN_ON for the combos that get stuff
wrong though (like only supply one side of the modifier info, not both).
> As a follow-up one could even go a step further, by erroring out when
> the driver hasn't provided valid modifier(s) and even removing
> config::allow_fb_modifiers all together.
Well that currently only exists to avoid walking the plane list (which we
need to do for validation that all planes are the same). It's quite tricky
code for tiny benefit, so I don't think it's worth it trying to remove
allow_fb_modifiers completely.
> Although for stable - this series + WARN_ON (no return since it might
> break buggy drivers) sounds good.
>
> > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > * @allow_fb_modifiers:
> > *
> > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > + * Note that drivers should not set this directly, it is automatically
> > + * set in drm_universal_plane_init().
> > *
> > * IMPORTANT:
> > *
> The new note and the existing IMPORTANT are in a weird mix.
> Quoting the latter since it doesn't show in the diff.
>
> If this is set the driver must fill out the full implicit modifier
> information in their &drm_mode_config_funcs.fb_create hook for legacy
> userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
> broken for modifier aware userspace.
>
> In particular:
> As the new note says "don't set it" and the existing note one says "if
> it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
>
> Sadly, nothing comes to mind atm wrt alternative wording.
Yeah it's a bit disappointing.
> With the WARN_ON() added or s/must/should/ in the documentation, the series is:
With my clarification, can you please recheck whether as-is it's not
correct?
Thanks, Daniel
> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
>
> HTH
> -Emil
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 12:22 ` [Intel-gfx] " Daniel Vetter
@ 2021-05-04 14:10 ` Emil Velikov
-1 siblings, 0 replies; 50+ messages in thread
From: Emil Velikov @ 2021-05-04 14:10 UTC (permalink / raw)
To: Daniel Vetter, Inki Dae
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter
Hi Daniel,
Thanks for the extra clarification.
On Tue, 27 Apr 2021 at 13:22, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> > Hi Daniel,
> >
> > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> > > * drm_universal_plane_init() to let the DRM managed resource infrastructure
> > > * take care of cleanup and deallocation.
> > > *
> > > + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> > > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> > > + *
> > The comment says "must", yet we have an "if (format_modifiers)" in the codebase.
> > Shouldn't we add a WARN_ON() + return -EINVAL (or similar) so people
> > can see and fix their drivers?
>
> This is a must only for drivers supporting modifiers, not all drivers.
> Hence the check in the if. I did add WARN_ON for the combos that get stuff
> wrong though (like only supply one side of the modifier info, not both).
>
Hmm you're spot on - the arm/malidp patch threw me off for a minute.
> > As a follow-up one could even go a step further, by erroring out when
> > the driver hasn't provided valid modifier(s) and even removing
> > config::allow_fb_modifiers all together.
>
> Well that currently only exists to avoid walking the plane list (which we
> need to do for validation that all planes are the same). It's quite tricky
> code for tiny benefit, so I don't think it's worth it trying to remove
> allow_fb_modifiers completely.
>
Pardon if I'm saying something painfully silly - it's been a while
since I've looked closely at KMS.
From some grepping around, removing ::allow_fb_modifiers would be OK
although it's a secondary goal. It feels like the bigger win will be
simpler modifier handling in DRM.
In particular, one could always "inject" the linear modifier within
drm_universal_plane_init() and always expose DRM_CAP_ADDFB2_MODIFIERS.
Some drivers mxsfb, mgag200, stm and likely others already advertise
the CAP, even though they seemingly lack any modifiers.
The linear/invalid cargo-cult to drm_universal_plane_init() seems
strong and this series adds even more.
Another plus of always exposing the CAP, is that one could mandate (or
nuke) optional .format_mod_supported that you/Ville discussed
earlier[1].
Currently things are weird, since it's required to create IN_FORMAT
blob, yet drivers lack it while simultaneously exposing the CAP to
userspace.
One such example is exynos... Although recently it recently dropped
`allow_fb_modifiers = true` and there are no modifiers passed to
drm_universal_plane_init(), so the CAP is no longer supported.
Inki you might want to check, if that broke your userspace.
Tl:Dr: There _might_ be value in simplifying the modifier handling
_after_ these fixes land.
[1] https://lore.kernel.org/dri-devel/CAKMK7uGNP5us8KFffnPwq7g4b0-B2q-m7deqz_rPHtCrh_qUTw@mail.gmail.com/
> > Although for stable - this series + WARN_ON (no return since it might
> > break buggy drivers) sounds good.
> >
> > > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > > * @allow_fb_modifiers:
> > > *
> > > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > > + * Note that drivers should not set this directly, it is automatically
> > > + * set in drm_universal_plane_init().
> > > *
> > > * IMPORTANT:
> > > *
> > The new note and the existing IMPORTANT are in a weird mix.
> > Quoting the latter since it doesn't show in the diff.
> >
> > If this is set the driver must fill out the full implicit modifier
> > information in their &drm_mode_config_funcs.fb_create hook for legacy
> > userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
> > broken for modifier aware userspace.
> >
> > In particular:
> > As the new note says "don't set it" and the existing note one says "if
> > it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
> >
> > Sadly, nothing comes to mind atm wrt alternative wording.
>
> Yeah it's a bit disappointing.
>
> > With the WARN_ON() added or s/must/should/ in the documentation, the series is:
>
> With my clarification, can you please recheck whether as-is it's not
> correct?
>
Indeed - with the series as-is my RB stands.
Thanks
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-05-04 14:10 ` Emil Velikov
0 siblings, 0 replies; 50+ messages in thread
From: Emil Velikov @ 2021-05-04 14:10 UTC (permalink / raw)
To: Daniel Vetter, Inki Dae
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter
Hi Daniel,
Thanks for the extra clarification.
On Tue, 27 Apr 2021 at 13:22, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Apr 27, 2021 at 12:32:19PM +0100, Emil Velikov wrote:
> > Hi Daniel,
> >
> > On Tue, 27 Apr 2021 at 10:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> > > * drm_universal_plane_init() to let the DRM managed resource infrastructure
> > > * take care of cleanup and deallocation.
> > > *
> > > + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> > > + * even those that only support DRM_FORMAT_MOD_LINEAR.
> > > + *
> > The comment says "must", yet we have an "if (format_modifiers)" in the codebase.
> > Shouldn't we add a WARN_ON() + return -EINVAL (or similar) so people
> > can see and fix their drivers?
>
> This is a must only for drivers supporting modifiers, not all drivers.
> Hence the check in the if. I did add WARN_ON for the combos that get stuff
> wrong though (like only supply one side of the modifier info, not both).
>
Hmm you're spot on - the arm/malidp patch threw me off for a minute.
> > As a follow-up one could even go a step further, by erroring out when
> > the driver hasn't provided valid modifier(s) and even removing
> > config::allow_fb_modifiers all together.
>
> Well that currently only exists to avoid walking the plane list (which we
> need to do for validation that all planes are the same). It's quite tricky
> code for tiny benefit, so I don't think it's worth it trying to remove
> allow_fb_modifiers completely.
>
Pardon if I'm saying something painfully silly - it's been a while
since I've looked closely at KMS.
From some grepping around, removing ::allow_fb_modifiers would be OK
although it's a secondary goal. It feels like the bigger win will be
simpler modifier handling in DRM.
In particular, one could always "inject" the linear modifier within
drm_universal_plane_init() and always expose DRM_CAP_ADDFB2_MODIFIERS.
Some drivers mxsfb, mgag200, stm and likely others already advertise
the CAP, even though they seemingly lack any modifiers.
The linear/invalid cargo-cult to drm_universal_plane_init() seems
strong and this series adds even more.
Another plus of always exposing the CAP, is that one could mandate (or
nuke) optional .format_mod_supported that you/Ville discussed
earlier[1].
Currently things are weird, since it's required to create IN_FORMAT
blob, yet drivers lack it while simultaneously exposing the CAP to
userspace.
One such example is exynos... Although recently it recently dropped
`allow_fb_modifiers = true` and there are no modifiers passed to
drm_universal_plane_init(), so the CAP is no longer supported.
Inki you might want to check, if that broke your userspace.
Tl:Dr: There _might_ be value in simplifying the modifier handling
_after_ these fixes land.
[1] https://lore.kernel.org/dri-devel/CAKMK7uGNP5us8KFffnPwq7g4b0-B2q-m7deqz_rPHtCrh_qUTw@mail.gmail.com/
> > Although for stable - this series + WARN_ON (no return since it might
> > break buggy drivers) sounds good.
> >
> > > @@ -909,6 +909,8 @@ struct drm_mode_config {
> > > * @allow_fb_modifiers:
> > > *
> > > * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > > + * Note that drivers should not set this directly, it is automatically
> > > + * set in drm_universal_plane_init().
> > > *
> > > * IMPORTANT:
> > > *
> > The new note and the existing IMPORTANT are in a weird mix.
> > Quoting the latter since it doesn't show in the diff.
> >
> > If this is set the driver must fill out the full implicit modifier
> > information in their &drm_mode_config_funcs.fb_create hook for legacy
> > userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
> > broken for modifier aware userspace.
> >
> > In particular:
> > As the new note says "don't set it" and the existing note one says "if
> > it's set". Yet no drivers do "if (config->allow_fb_modifiers)".
> >
> > Sadly, nothing comes to mind atm wrt alternative wording.
>
> Yeah it's a bit disappointing.
>
> > With the WARN_ON() added or s/must/should/ in the documentation, the series is:
>
> With my clarification, can you please recheck whether as-is it's not
> correct?
>
Indeed - with the series as-is my RB stands.
Thanks
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-05-04 14:10 ` [Intel-gfx] " Emil Velikov
@ 2021-05-04 14:58 ` Simon Ser
-1 siblings, 0 replies; 50+ messages in thread
From: Simon Ser @ 2021-05-04 14:58 UTC (permalink / raw)
To: Emil Velikov
Cc: Pekka Paalanen, Thomas Zimmermann, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Maxime Ripard,
Daniel Vetter
Continuing on that idea to push for enabling the cap in more cases: do
we have a policy to require new drivers to always support modifiers?
That would be nice, even if it's just about enabling LINEAR.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-05-04 14:58 ` Simon Ser
0 siblings, 0 replies; 50+ messages in thread
From: Simon Ser @ 2021-05-04 14:58 UTC (permalink / raw)
To: Emil Velikov
Cc: Pekka Paalanen, Thomas Zimmermann, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Inki Dae,
Maxime Ripard, Daniel Vetter
Continuing on that idea to push for enabling the cap in more cases: do
we have a policy to require new drivers to always support modifiers?
That would be nice, even if it's just about enabling LINEAR.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-05-04 14:58 ` [Intel-gfx] " Simon Ser
@ 2021-05-04 15:48 ` Emil Velikov
-1 siblings, 0 replies; 50+ messages in thread
From: Emil Velikov @ 2021-05-04 15:48 UTC (permalink / raw)
To: Simon Ser
Cc: Pekka Paalanen, Thomas Zimmermann, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Maxime Ripard,
Daniel Vetter
On Tue, 4 May 2021 at 15:58, Simon Ser <contact@emersion.fr> wrote:
>
> Continuing on that idea to push for enabling the cap in more cases: do
> we have a policy to require new drivers to always support modifiers?
>
> That would be nice, even if it's just about enabling LINEAR.
Sounds perfectly reasonable IMHO. I think we ought to document this
policy (requirement ideally) somewhere - say alongside the "all new
KMS drivers must support atomic modeset", which lives in ...
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-05-04 15:48 ` Emil Velikov
0 siblings, 0 replies; 50+ messages in thread
From: Emil Velikov @ 2021-05-04 15:48 UTC (permalink / raw)
To: Simon Ser
Cc: Pekka Paalanen, Thomas Zimmermann, David Airlie, Daniel Vetter,
Intel Graphics Development, DRI Development, Inki Dae,
Maxime Ripard, Daniel Vetter
On Tue, 4 May 2021 at 15:58, Simon Ser <contact@emersion.fr> wrote:
>
> Continuing on that idea to push for enabling the cap in more cases: do
> we have a policy to require new drivers to always support modifiers?
>
> That would be nice, even if it's just about enabling LINEAR.
Sounds perfectly reasonable IMHO. I think we ought to document this
policy (requirement ideally) somewhere - say alongside the "all new
KMS drivers must support atomic modeset", which lives in ...
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-05-04 13:38 ` Pekka Paalanen
-1 siblings, 0 replies; 50+ messages in thread
From: Pekka Paalanen @ 2021-05-04 13:38 UTC (permalink / raw)
To: Daniel Vetter
Cc: David Airlie, Intel Graphics Development, DRI Development,
Maxime Ripard, Thomas Zimmermann, Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 3989 bytes --]
On Tue, 27 Apr 2021 11:20:18 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
> Cc: Simon Ser <contact@emersion.fr>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
> drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
I can only say about the doc parts, but:
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
For patches 2 and 5 too, on the grounds that the idea is good.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-05-04 13:38 ` Pekka Paalanen
0 siblings, 0 replies; 50+ messages in thread
From: Pekka Paalanen @ 2021-05-04 13:38 UTC (permalink / raw)
To: Daniel Vetter
Cc: David Airlie, Intel Graphics Development, DRI Development,
Maxime Ripard, Thomas Zimmermann, Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 3989 bytes --]
On Tue, 27 Apr 2021 11:20:18 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
> Cc: Simon Ser <contact@emersion.fr>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
> drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
I can only say about the doc parts, but:
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
For patches 2 and 5 too, on the grounds that the idea is good.
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-05-05 19:24 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-05-05 19:24 UTC (permalink / raw)
To: DRI Development, Lyude
Cc: Pekka Paalanen, David Airlie, Intel Graphics Development,
Maxime Ripard, Thomas Zimmermann, Daniel Vetter
On Tue, Apr 27, 2021 at 11:20 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
> Cc: Simon Ser <contact@emersion.fr>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
Lyude's irc review:
<Lyude> btw danvet (sorry I didn't reply in-line, for some reason I
can't actually seem to find the emails for your allow_fb_modifiers
series in my email client), I just looked over your allow_fb_modifiers
series and everything looks fine with one comment:
https://lore.kernel.org/dri-devel/20210427092018.832258-8-daniel.vetter@ffwll.ch/
we should probably use drm_WARN_ON() here instead
<Lyude> with that fixed: Reviewed-by: Lyude Paul <lyude@redhat.com>
I'll merge the driver patches and respin this one afterwards.
-Daniel
> ---
> drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
> --
> 2.31.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-05-05 19:24 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-05-05 19:24 UTC (permalink / raw)
To: DRI Development, Lyude
Cc: Pekka Paalanen, David Airlie, Simon Ser,
Intel Graphics Development, Maxime Ripard, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter, Lucas Stach
On Tue, Apr 27, 2021 at 11:20 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
> Cc: Simon Ser <contact@emersion.fr>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
Lyude's irc review:
<Lyude> btw danvet (sorry I didn't reply in-line, for some reason I
can't actually seem to find the emails for your allow_fb_modifiers
series in my email client), I just looked over your allow_fb_modifiers
series and everything looks fine with one comment:
https://lore.kernel.org/dri-devel/20210427092018.832258-8-daniel.vetter@ffwll.ch/
we should probably use drm_WARN_ON() here instead
<Lyude> with that fixed: Reviewed-by: Lyude Paul <lyude@redhat.com>
I'll merge the driver patches and respin this one afterwards.
-Daniel
> ---
> drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
> --
> 2.31.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-05-06 9:55 ` Daniel Vetter
-1 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-05-06 9:55 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, Maxime Ripard, Thomas Zimmermann,
Daniel Vetter
On Tue, Apr 27, 2021 at 11:20:18AM +0200, Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
> Cc: Simon Ser <contact@emersion.fr>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
I merged all the driver patches to drm-misc-next, I'll resend v3 of this
one shortly.
-Daniel
> ---
> drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
> --
> 2.31.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
@ 2021-05-06 9:55 ` Daniel Vetter
0 siblings, 0 replies; 50+ messages in thread
From: Daniel Vetter @ 2021-05-06 9:55 UTC (permalink / raw)
To: DRI Development
Cc: Pekka Paalanen, David Airlie, Daniel Vetter,
Intel Graphics Development, Maxime Ripard, Maxime Ripard,
Thomas Zimmermann, Simon Ser, Daniel Vetter, Lucas Stach
On Tue, Apr 27, 2021 at 11:20:18AM +0200, Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
> Cc: Simon Ser <contact@emersion.fr>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
I merged all the driver patches to drm-misc-next, I'll resend v3 of this
one shortly.
-Daniel
> ---
> drivers/gpu/drm/drm_plane.c | 18 +++++++++++++++++-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
> *
> * IMPORTANT:
> *
> --
> 2.31.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/arm: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
` (7 preceding siblings ...)
(?)
@ 2021-04-27 10:58 ` Patchwork
-1 siblings, 0 replies; 50+ messages in thread
From: Patchwork @ 2021-04-27 10:58 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/8] drm/arm: Don't set allow_fb_modifiers explicitly
URL : https://patchwork.freedesktop.org/series/89531/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6bdfcd621a6a drm/arm: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 890880ddfdbe ("drm: Auto-set allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:47: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
9d02b5e6f19f drm/arm/malidp: Always list modifiers
-:23: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
#23: FILE: drivers/gpu/drm/arm/malidp_planes.c:930:
+static const uint64_t linear_only_modifiers[] = {
-:41: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 1 checks, 21 lines checked
4ba63830af10 drm/i915: Don't set allow_fb_modifiers explicitly
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 890880ddfdbe ("drm: Auto-set allow_fb_modifiers when given modifiers at plane init")'
#11:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:44: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
64a789bb0aab drm/msm/dpu1: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 890880ddfdbe ("drm: Auto-set allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:44: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 11 lines checked
e77663da9c1f drm/msm/mdp4: Fix modifier support enabling
-:41: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t'
#41: FILE: drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c:352:
+static const uint64_t supported_format_modifiers[] = {
-:58: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 1 checks, 28 lines checked
940e48334301 drm/nouveau: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 890880ddfdbe ("drm: Auto-set allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:38: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 7 lines checked
899a5341c78f drm/stm: Don't set allow_fb_modifiers explicitly
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 890880ddfdbe ("drm: Auto-set allow_fb_modifiers when given modifiers at plane init")'
#8:
commit 890880ddfdbe256083170866e49c87618b706ac7
-:38: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
1aee8463efc8 drm/modifiers: Enforce consistency between the cap an IN_FORMATS
-:8: WARNING:TYPO_SPELLING: 'ommitted' may be misspelled - perhaps 'omitted'?
#8:
here, and some drivers screwed this up a bit. Most just ommitted the
^^^^^^^^
-:89: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 2 warnings, 0 checks, 45 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/arm: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
` (8 preceding siblings ...)
(?)
@ 2021-04-27 11:28 ` Patchwork
-1 siblings, 0 replies; 50+ messages in thread
From: Patchwork @ 2021-04-27 11:28 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 4043 bytes --]
== Series Details ==
Series: series starting with [1/8] drm/arm: Don't set allow_fb_modifiers explicitly
URL : https://patchwork.freedesktop.org/series/89531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10015 -> Patchwork_19999
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_19999:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_create@basic:
- {fi-cml-drallion}: NOTRUN -> [INCOMPLETE][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/fi-cml-drallion/igt@gem_exec_create@basic.html
Known issues
------------
Here are the changes found in Patchwork_19999 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-tgl-y: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/fi-tgl-y/igt@amdgpu/amd_prime@amd-to-i915.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/fi-tgl-u2/igt@gem_exec_suspend@basic-s3.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/fi-tgl-u2/igt@gem_exec_suspend@basic-s3.html
#### Possible fixes ####
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [DMESG-WARN][5] ([i915#2867] / [i915#3240]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@workarounds:
- fi-tgl-u2: [DMESG-WARN][7] ([i915#2867]) -> [PASS][8] +15 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/fi-tgl-u2/igt@i915_selftest@live@workarounds.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/fi-tgl-u2/igt@i915_selftest@live@workarounds.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3240]: https://gitlab.freedesktop.org/drm/intel/issues/3240
Participating hosts (40 -> 39)
------------------------------
Additional (1): fi-cml-drallion
Missing (2): fi-bsw-cyan fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_10015 -> Patchwork_19999
CI-20190529: 20190529
CI_DRM_10015: feeb8bdec63b698624bf3c2f7970c5dbed6709cd @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6076: 9ab0820dbd07781161c1ace6973ea222fd24e53a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19999: 1aee8463efc8483a708bb75301d38994fbfbdc46 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1aee8463efc8 drm/modifiers: Enforce consistency between the cap an IN_FORMATS
899a5341c78f drm/stm: Don't set allow_fb_modifiers explicitly
940e48334301 drm/nouveau: Don't set allow_fb_modifiers explicitly
e77663da9c1f drm/msm/mdp4: Fix modifier support enabling
64a789bb0aab drm/msm/dpu1: Don't set allow_fb_modifiers explicitly
4ba63830af10 drm/i915: Don't set allow_fb_modifiers explicitly
9d02b5e6f19f drm/arm/malidp: Always list modifiers
6bdfcd621a6a drm/arm: Don't set allow_fb_modifiers explicitly
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/index.html
[-- Attachment #1.2: Type: text/html, Size: 4889 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
@ 2021-04-27 15:25 ` Liviu Dudau
-1 siblings, 0 replies; 50+ messages in thread
From: Liviu Dudau @ 2021-04-27 15:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: Intel Graphics Development, DRI Development, James (Qian) Wang,
Daniel Vetter, Mihail Atanassov
On Tue, Apr 27, 2021 at 11:20:11AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here for both komeda and
> malidp.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> Cc: Mihail Atanassov <mihail.atanassov@arm.com>
> Cc: Brian Starkey <brian.starkey@arm.com>
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 -
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index aeda4e5ec4f4..ff45f23f3d56 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -247,7 +247,6 @@ static void komeda_kms_mode_config_init(struct komeda_kms_dev *kms,
> config->min_height = 0;
> config->max_width = 4096;
> config->max_height = 4096;
> - config->allow_fb_modifiers = true;
>
> config->funcs = &komeda_mode_config_funcs;
> config->helper_private = &komeda_mode_config_helpers;
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index d83c7366b348..de59f3302516 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -403,7 +403,6 @@ static int malidp_init(struct drm_device *drm)
> drm->mode_config.max_height = hwdev->max_line_size;
> drm->mode_config.funcs = &malidp_mode_config_funcs;
> drm->mode_config.helper_private = &malidp_mode_config_helpers;
> - drm->mode_config.allow_fb_modifiers = true;
>
> ret = malidp_crtc_init(drm);
> if (ret)
> --
> 2.31.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [Intel-gfx] [PATCH 1/8] drm/arm: Don't set allow_fb_modifiers explicitly
@ 2021-04-27 15:25 ` Liviu Dudau
0 siblings, 0 replies; 50+ messages in thread
From: Liviu Dudau @ 2021-04-27 15:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: Intel Graphics Development, DRI Development, James (Qian) Wang,
Daniel Vetter, Mihail Atanassov
On Tue, Apr 27, 2021 at 11:20:11AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here for both komeda and
> malidp.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> Cc: Mihail Atanassov <mihail.atanassov@arm.com>
> Cc: Brian Starkey <brian.starkey@arm.com>
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 -
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index aeda4e5ec4f4..ff45f23f3d56 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -247,7 +247,6 @@ static void komeda_kms_mode_config_init(struct komeda_kms_dev *kms,
> config->min_height = 0;
> config->max_width = 4096;
> config->max_height = 4096;
> - config->allow_fb_modifiers = true;
>
> config->funcs = &komeda_mode_config_funcs;
> config->helper_private = &komeda_mode_config_helpers;
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index d83c7366b348..de59f3302516 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -403,7 +403,6 @@ static int malidp_init(struct drm_device *drm)
> drm->mode_config.max_height = hwdev->max_line_size;
> drm->mode_config.funcs = &malidp_mode_config_funcs;
> drm->mode_config.helper_private = &malidp_mode_config_helpers;
> - drm->mode_config.allow_fb_modifiers = true;
>
> ret = malidp_crtc_init(drm);
> if (ret)
> --
> 2.31.0
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] drm/arm: Don't set allow_fb_modifiers explicitly
2021-04-27 9:20 ` [Intel-gfx] " Daniel Vetter
` (10 preceding siblings ...)
(?)
@ 2021-04-27 15:46 ` Patchwork
-1 siblings, 0 replies; 50+ messages in thread
From: Patchwork @ 2021-04-27 15:46 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 30298 bytes --]
== Series Details ==
Series: series starting with [1/8] drm/arm: Don't set allow_fb_modifiers explicitly
URL : https://patchwork.freedesktop.org/series/89531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10015_full -> Patchwork_19999_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_19999_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@gem_create@create-massive.html
* igt@gem_ctx_persistence@engines-queued:
- shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +1 similar issue
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-snb7/igt@gem_ctx_persistence@engines-queued.html
* igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][3] ([i915#3316])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl1/igt@gem_ctx_ringsize@idle@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-skl: NOTRUN -> [FAIL][4] ([i915#2846])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][5] ([i915#2842])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-glk7/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-glk6/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl: NOTRUN -> [FAIL][8] ([i915#2389]) +3 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@gem_exec_reloc@basic-wide-active@bcs0.html
* igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb: NOTRUN -> [FAIL][9] ([i915#2389]) +2 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-snb2/igt@gem_exec_reloc@basic-wide-active@rcs0.html
* igt@gem_mmap_gtt@cpuset-medium-copy-odd:
- shard-skl: [PASS][10] -> [FAIL][11] ([i915#307])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl1/igt@gem_mmap_gtt@cpuset-medium-copy-odd.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl1/igt@gem_mmap_gtt@cpuset-medium-copy-odd.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [WARN][12] ([i915#2658])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl6/igt@gem_pread@exhaustion.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3323])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl1/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gem_userptr_blits@vma-merge:
- shard-apl: NOTRUN -> [FAIL][14] ([i915#3318])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl1/igt@gem_userptr_blits@vma-merge.html
* igt@gen9_exec_parse@bb-large:
- shard-skl: NOTRUN -> [FAIL][15] ([i915#3296])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@gen9_exec_parse@bb-large.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: NOTRUN -> [FAIL][16] ([i915#2521])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl1/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_big_joiner@invalid-modeset:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2705])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer:
- shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111304])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@kms_ccs@pipe-c-missing-ccs-buffer.html
* igt@kms_chamelium@dp-mode-timings:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +31 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl1/igt@kms_chamelium@dp-mode-timings.html
* igt@kms_color@pipe-c-ctm-green-to-red:
- shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1982])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl3/igt@kms_color@pipe-c-ctm-green-to-red.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@kms_color@pipe-c-ctm-green-to-red.html
* igt@kms_color_chamelium@pipe-b-ctm-max:
- shard-skl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +11 similar issues
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@kms_color_chamelium@pipe-b-ctm-max.html
* igt@kms_color_chamelium@pipe-c-gamma:
- shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271] / [fdo#111827]) +5 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl7/igt@kms_color_chamelium@pipe-c-gamma.html
* igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes:
- shard-snb: NOTRUN -> [SKIP][24] ([fdo#109271] / [fdo#111827]) +11 similar issues
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-snb6/igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes.html
* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][25] ([i915#1319])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl7/igt@kms_content_protection@lic.html
* igt@kms_content_protection@uevent:
- shard-kbl: NOTRUN -> [FAIL][26] ([i915#2105])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@kms_content_protection@uevent.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
- shard-apl: NOTRUN -> [FAIL][27] ([i915#54])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-apl: [PASS][28] -> [DMESG-WARN][29] ([i915#180]) +1 similar issue
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-apl6/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl6/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-iclb: [PASS][30] -> [INCOMPLETE][31] ([i915#1185])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb8/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl: [PASS][32] -> [FAIL][33] ([i915#2346])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl5/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl4/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-apl: NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#533]) +1 similar issue
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl7/igt@kms_cursor_legacy@pipe-d-torture-bo.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][35] -> [INCOMPLETE][36] ([i915#155] / [i915#180] / [i915#636])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [PASS][37] -> [FAIL][38] ([i915#2122]) +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-suspend@a-edp1:
- shard-skl: [PASS][39] -> [INCOMPLETE][40] ([i915#198] / [i915#1982])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl10/igt@kms_flip@flip-vs-suspend@a-edp1.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl1/igt@kms_flip@flip-vs-suspend@a-edp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: [PASS][41] -> [DMESG-WARN][42] ([i915#180]) +6 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl4/igt@kms_flip@flip-vs-suspend@c-dp1.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl1/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- shard-skl: NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#2672])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl1/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
- shard-apl: NOTRUN -> [SKIP][44] ([fdo#109271] / [i915#2672])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl7/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
- shard-skl: NOTRUN -> [SKIP][45] ([fdo#109271] / [i915#2642])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
- shard-snb: NOTRUN -> [SKIP][46] ([fdo#109271]) +202 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-snb2/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
- shard-apl: NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#2642])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
- shard-kbl: NOTRUN -> [SKIP][48] ([fdo#109271] / [i915#2672])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt:
- shard-kbl: NOTRUN -> [SKIP][49] ([fdo#109271]) +92 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack-mmap-gtt:
- shard-skl: NOTRUN -> [SKIP][50] ([fdo#109271]) +160 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl9/igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack-mmap-gtt.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][51] -> [FAIL][52] ([i915#1188])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl8/igt@kms_hdr@bpc-switch-dpms.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl6/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-d:
- shard-kbl: NOTRUN -> [SKIP][53] ([fdo#109271] / [i915#533])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@kms_pipe_crc_basic@hang-read-crc-pipe-d.html
* igt@kms_pipe_crc_basic@read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#533]) +1 similar issue
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@kms_pipe_crc_basic@read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> [FAIL][55] ([fdo#108145] / [i915#265]) +2 similar issues
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: NOTRUN -> [FAIL][56] ([fdo#108145] / [i915#265])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][57] -> [FAIL][58] ([fdo#108145] / [i915#265])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-kbl: NOTRUN -> [FAIL][59] ([fdo#108145] / [i915#265])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][60] ([i915#265])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl7/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html
- shard-skl: NOTRUN -> [FAIL][61] ([i915#265])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html
* igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- shard-apl: NOTRUN -> [SKIP][62] ([fdo#109271] / [i915#2733])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2:
- shard-kbl: NOTRUN -> [SKIP][63] ([fdo#109271] / [i915#658]) +2 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl4/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1:
- shard-skl: NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#658])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4:
- shard-apl: NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#658]) +5 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][66] -> [SKIP][67] ([fdo#109642] / [fdo#111068] / [i915#658])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb2/igt@kms_psr2_su@page_flip.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb6/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_primary_blt:
- shard-iclb: [PASS][68] -> [SKIP][69] ([fdo#109441]) +1 similar issue
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb2/igt@kms_psr@psr2_primary_blt.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb6/igt@kms_psr@psr2_primary_blt.html
* igt@kms_setmode@basic:
- shard-snb: NOTRUN -> [FAIL][70] ([i915#31])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-snb7/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-d-wait-forked-hang:
- shard-apl: NOTRUN -> [SKIP][71] ([fdo#109271]) +272 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_vblank@pipe-d-wait-forked-hang.html
* igt@kms_writeback@writeback-invalid-parameters:
- shard-apl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#2437])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_writeback@writeback-invalid-parameters.html
* igt@perf@polling:
- shard-skl: [PASS][73] -> [FAIL][74] ([i915#1542])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl8/igt@perf@polling.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl5/igt@perf@polling.html
* igt@sysfs_clients@fair-3:
- shard-kbl: NOTRUN -> [SKIP][75] ([fdo#109271] / [i915#2994]) +3 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@sysfs_clients@fair-3.html
* igt@sysfs_clients@sema-50:
- shard-apl: NOTRUN -> [SKIP][76] ([fdo#109271] / [i915#2994]) +4 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl3/igt@sysfs_clients@sema-50.html
* igt@sysfs_clients@split-50:
- shard-skl: NOTRUN -> [SKIP][77] ([fdo#109271] / [i915#2994])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@sysfs_clients@split-50.html
#### Possible fixes ####
* igt@drm_mm@all@insert:
- shard-skl: [INCOMPLETE][78] ([i915#2485] / [i915#2502]) -> [PASS][79]
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl3/igt@drm_mm@all@insert.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl8/igt@drm_mm@all@insert.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl: [INCOMPLETE][80] ([i915#198]) -> [PASS][81]
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl9/igt@gem_ctx_isolation@preservation-s3@rcs0.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl9/igt@gem_ctx_isolation@preservation-s3@rcs0.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [TIMEOUT][82] ([i915#2369] / [i915#2481] / [i915#3070]) -> [PASS][83]
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb2/igt@gem_eio@unwedge-stress.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb6/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [FAIL][84] ([i915#2842]) -> [PASS][85] +2 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-tglb2/igt@gem_exec_fair@basic-flow@rcs0.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-tglb8/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][86] ([i915#2842]) -> [PASS][87] +2 similar issues
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl4/igt@gem_exec_fair@basic-none@vcs0.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl1/igt@gem_exec_fair@basic-none@vcs0.html
- shard-apl: [FAIL][88] ([i915#2842]) -> [PASS][89] +1 similar issue
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-apl2/igt@gem_exec_fair@basic-none@vcs0.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl6/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_reloc@basic-range:
- shard-tglb: [DMESG-WARN][90] -> [PASS][91] +2 similar issues
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-tglb5/igt@gem_exec_reloc@basic-range.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-tglb3/igt@gem_exec_reloc@basic-range.html
* igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [FAIL][92] ([i915#307]) -> [PASS][93]
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb6/igt@gem_mmap_gtt@cpuset-big-copy.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb7/igt@gem_mmap_gtt@cpuset-big-copy.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [DMESG-WARN][94] ([i915#1436] / [i915#716]) -> [PASS][95]
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl5/igt@gen9_exec_parse@allowed-single.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl7/igt@gen9_exec_parse@allowed-single.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [DMESG-WARN][96] ([i915#180]) -> [PASS][97] +3 similar issues
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-skl: [INCOMPLETE][98] -> [PASS][99]
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl3/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl6/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions.html
* igt@kms_flip@flip-vs-suspend-interruptible@b-dp1:
- shard-apl: [DMESG-WARN][100] ([i915#180]) -> [PASS][101]
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible@b-dp1.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@b-dp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
- shard-skl: [FAIL][102] ([i915#2122]) -> [PASS][103]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl8/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [FAIL][104] ([i915#1188]) -> [PASS][105]
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl4/igt@kms_hdr@bpc-switch-suspend.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [DMESG-WARN][106] ([i915#180] / [i915#533]) -> [PASS][107]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][108] ([fdo#108145] / [i915#265]) -> [PASS][109]
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [SKIP][110] ([fdo#109441]) -> [PASS][111] +1 similar issue
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb8/igt@kms_psr@psr2_cursor_plane_onoff.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
#### Warnings ####
* igt@gem_vm_create@destroy-race:
- shard-tglb: [FAIL][112] ([i915#2822]) -> [TIMEOUT][113] ([i915#2795])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-tglb1/igt@gem_vm_create@destroy-race.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-tglb2/igt@gem_vm_create@destroy-race.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][114] ([i915#2684]) -> [WARN][115] ([i915#1804] / [i915#2684])
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb2/igt@i915_pm_rc6_residency@rc6-fence.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb4/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: [WARN][116] ([i915#1804] / [i915#2684]) -> [WARN][117] ([i915#2681] / [i915#2684])
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb7/igt@i915_pm_rc6_residency@rc6-idle.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb1/igt@i915_pm_rc6_residency@rc6-idle.html
* igt@kms_3d:
- shard-apl: [SKIP][118] ([fdo#109271] / [i915#483]) -> [SKIP][119] ([fdo#109271])
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-apl3/igt@kms_3d.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl3/igt@kms_3d.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
- shard-iclb: [SKIP][120] ([i915#658]) -> [SKIP][121] ([i915#2920]) +2 similar issues
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb8/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4:
- shard-iclb: [SKIP][122] ([i915#2920]) -> [SKIP][123] ([i915#658])
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-iclb4/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-4.html
* igt@runner@aborted:
- shard-kbl: ([FAIL][124], [FAIL][125], [FAIL][126], [FAIL][127], [FAIL][128], [FAIL][129], [FAIL][130], [FAIL][131]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#2505] / [i915#3002]) -> ([FAIL][132], [FAIL][133], [FAIL][134], [FAIL][135], [FAIL][136], [FAIL][137], [FAIL][138]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#2505] / [i915#3002] / [i915#92])
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl2/igt@runner@aborted.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl1/igt@runner@aborted.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl1/igt@runner@aborted.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl1/igt@runner@aborted.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl1/igt@runner@aborted.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl2/igt@runner@aborted.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl6/igt@runner@aborted.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-kbl2/igt@runner@aborted.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl6/igt@runner@aborted.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl4/igt@runner@aborted.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl2/igt@runner@aborted.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl1/igt@runner@aborted.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl1/igt@runner@aborted.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl2/igt@runner@aborted.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-kbl1/igt@runner@aborted.html
- shard-apl: ([FAIL][139], [FAIL][140]) ([i915#180] / [i915#3002]) -> ([FAIL][141], [FAIL][142], [FAIL][143], [FAIL][144]) ([i915#1610] / [i915#1814] / [i915#3002])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-apl8/igt@runner@aborted.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-apl6/igt@runner@aborted.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl6/igt@runner@aborted.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl2/igt@runner@aborted.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl1/igt@runner@aborted.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-apl1/igt@runner@aborted.html
- shard-skl: ([FAIL][145], [FAIL][146], [FAIL][147], [FAIL][148], [FAIL][149], [FAIL][150]) ([i915#1436] / [i915#1814] / [i915#2029] / [i915#2485] / [i915#3002]) -> ([FAIL][151], [FAIL][152], [FAIL][153], [FAIL][154], [FAIL][155], [FAIL][156], [FAIL][157]) ([i915#1814] / [i915#2029] / [i915#3002])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl5/igt@runner@aborted.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl3/igt@runner@aborted.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl4/igt@runner@aborted.html
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl3/igt@runner@aborted.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl5/igt@runner@aborted.html
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10015/shard-skl3/igt@runner@aborted.html
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl3/igt@runner@aborted.html
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl2/igt@runner@aborted.html
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl4/igt@runner@aborted.html
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl5/igt@runner@aborted.html
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl10/igt@runner@aborted.html
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/shard-skl3/igt@runner@aborted.html
[157]: ht
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19999/index.html
[-- Attachment #1.2: Type: text/html, Size: 33758 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 50+ messages in thread