Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel
On Thu, Jan 12, 2017 at 10:56:17AM -0800, Ben Widawsky wrote:
> On 17-01-12 20:32:07, Ville Syrjälä wrote:
> >On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:
> >> On 17-01-12 12:51:20, Ville Syrjälä wrote:
> >> >On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> >> >> This was based on a patch originally by Kristian. It has been modified
> >> >> pretty heavily to use the new callbacks from the previous patch.
> >> >>
> >> >> Cc: Kristian H. Kristensen
> >> >> Signed-off-by: Ben Widawsky
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_display.c | 109
> >> >> ++-
> >> >> drivers/gpu/drm/i915/intel_sprite.c | 33 ++-
> >> >> 2 files changed, 137 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> >> b/drivers/gpu/drm/i915/intel_display.c
> >> >> index 8715b1083d1d..26f3a911b999 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> >> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
> >> >> DRM_FORMAT_XRGB,
> >> >> };
> >> >>
> >> >> +static const uint64_t i8xx_format_modifiers[] = {
> >> >> + I915_FORMAT_MOD_X_TILED,
> >> >
> >> >Did we want to list the linear modifier in these as well?
> >> >
> >>
> >> Yeah. My initial response was no, but yes. We should. I was using
> >> DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be
> >> defined
> >> in the array.
> >>
> >> >> + DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >> +
> >> >> /* Primary plane formats for gen >= 4 */
> >> >> static const uint32_t i965_primary_formats[] = {
> >> >> DRM_FORMAT_C8,
> >> >> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
> >> >> DRM_FORMAT_XBGR2101010,
> >> >> };
> >> >>
> >> >> +static const uint64_t i965_format_modifiers[] = {
> >> >> + I915_FORMAT_MOD_X_TILED,
> >> >> + DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >
> >> >We could just share the i8xx array. The name of the array should perhaps
> >> >be i9xx_format_modifiers[] in that case. That's sort of the naming
> >> >convention we've been left with for things that apply to more or less
> >> >all the platforms.
> >> >
> >>
> >> Got it thanks. This is a relic from Kristian's original patch which tied
> >> the
> >> modifiers to the formats in place. It made more sense there to have a
> >> separate
> >> i8xx
> >>
> >> >> +
> >> >> static const uint32_t skl_primary_formats[] = {
> >> >> DRM_FORMAT_C8,
> >> >> DRM_FORMAT_RGB565,
> >> >> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
> >> >> DRM_FORMAT_VYUY,
> >> >> };
> >> >>
> >> >> +static const uint64_t skl_format_modifiers[] = {
> >> >> + I915_FORMAT_MOD_Y_TILED,
> >> >
> >> >Yf missing? and linear
> >> >
> >>
> >> Yes, thanks. I'm kind of scared to add Yf to be honest :P
> >>
> >> >> + I915_FORMAT_MOD_X_TILED,
> >> >> + DRM_FORMAT_MOD_INVALID
> >> >> +};
> >> >> +
> >> >> /* Cursor formats */
> >> >> static const uint32_t intel_cursor_formats[] = {
> >> >> DRM_FORMAT_ARGB,
> >> >> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane
> >> >> *plane)
> >> >> kfree(to_intel_plane(plane));
> >> >> }
> >> >>
> >> >> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> + if (modifier == DRM_FORMAT_MOD_NONE)
> >> >> + return true;
> >> >> +
> >> >> + switch (format) {
> >> >> + case DRM_FORMAT_C8:
> >> >> + case DRM_FORMAT_RGB565:
> >> >> + case DRM_FORMAT_XRGB1555:
> >> >> + case DRM_FORMAT_XRGB:
> >> >> + return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> + default:
> >> >> + return false;
> >> >> + }
> >> >> +}
> >> >> +
> >> >> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> >> >> +{
> >> >> + switch (format) {
> >> >> + case DRM_FORMAT_C8:
> >> >> + case DRM_FORMAT_RGB565:
> >> >> + case DRM_FORMAT_XRGB:
> >> >> + case DRM_FORMAT_XBGR:
> >> >> + case DRM_FORMAT_XRGB2101010:
> >> >> + case DRM_FORMAT_XBGR2101010:
> >> >> + return modifier == I915_FORMAT_MOD_X_TILED;
> >> >> + default:
> >> >> + return false;
> >> >> + }
> >> >> +}
> >> >
> >> >Hmm. There should be no format vs. tiling restrictions on these
> >> >platforms, so presumably a simple "return true" should cover it all.
> >> >That does perhaps remove the usefulness of these functions for
> >> >verifying that the format or modifier is supported at all
> >>
> >> One of the reasons for changing to this current format-modifier lookup at
> >> all
> >> was Kristian's approach was considered fragile. If for whatever reason
> >> formats
> >> are added, or removed, we'll catch it here. Also, it maybe let's us do
> >> something
> >> on cursor plane at
Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel
On 17-01-12 20:32:07, Ville Syrjälä wrote:
On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:
On 17-01-12 12:51:20, Ville Syrjälä wrote:
>On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
>> This was based on a patch originally by Kristian. It has been modified
>> pretty heavily to use the new callbacks from the previous patch.
>>
>> Cc: Kristian H. Kristensen
>> Signed-off-by: Ben Widawsky
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 109
++-
>> drivers/gpu/drm/i915/intel_sprite.c | 33 ++-
>> 2 files changed, 137 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
>> index 8715b1083d1d..26f3a911b999 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
>>DRM_FORMAT_XRGB,
>> };
>>
>> +static const uint64_t i8xx_format_modifiers[] = {
>> + I915_FORMAT_MOD_X_TILED,
>
>Did we want to list the linear modifier in these as well?
>
Yeah. My initial response was no, but yes. We should. I was using
DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be defined
in the array.
>> + DRM_FORMAT_MOD_INVALID
>> +};
>> +
>> /* Primary plane formats for gen >= 4 */
>> static const uint32_t i965_primary_formats[] = {
>>DRM_FORMAT_C8,
>> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
>>DRM_FORMAT_XBGR2101010,
>> };
>>
>> +static const uint64_t i965_format_modifiers[] = {
>> + I915_FORMAT_MOD_X_TILED,
>> + DRM_FORMAT_MOD_INVALID
>> +};
>
>We could just share the i8xx array. The name of the array should perhaps
>be i9xx_format_modifiers[] in that case. That's sort of the naming
>convention we've been left with for things that apply to more or less
>all the platforms.
>
Got it thanks. This is a relic from Kristian's original patch which tied the
modifiers to the formats in place. It made more sense there to have a separate
i8xx
>> +
>> static const uint32_t skl_primary_formats[] = {
>>DRM_FORMAT_C8,
>>DRM_FORMAT_RGB565,
>> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
>>DRM_FORMAT_VYUY,
>> };
>>
>> +static const uint64_t skl_format_modifiers[] = {
>> + I915_FORMAT_MOD_Y_TILED,
>
>Yf missing? and linear
>
Yes, thanks. I'm kind of scared to add Yf to be honest :P
>> + I915_FORMAT_MOD_X_TILED,
>> + DRM_FORMAT_MOD_INVALID
>> +};
>> +
>> /* Cursor formats */
>> static const uint32_t intel_cursor_formats[] = {
>>DRM_FORMAT_ARGB,
>> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
>>kfree(to_intel_plane(plane));
>> }
>>
>> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
>> +{
>> + if (modifier == DRM_FORMAT_MOD_NONE)
>> + return true;
>> +
>> + switch (format) {
>> + case DRM_FORMAT_C8:
>> + case DRM_FORMAT_RGB565:
>> + case DRM_FORMAT_XRGB1555:
>> + case DRM_FORMAT_XRGB:
>> + return modifier == I915_FORMAT_MOD_X_TILED;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
>> +{
>> + switch (format) {
>> + case DRM_FORMAT_C8:
>> + case DRM_FORMAT_RGB565:
>> + case DRM_FORMAT_XRGB:
>> + case DRM_FORMAT_XBGR:
>> + case DRM_FORMAT_XRGB2101010:
>> + case DRM_FORMAT_XBGR2101010:
>> + return modifier == I915_FORMAT_MOD_X_TILED;
>> + default:
>> + return false;
>> + }
>> +}
>
>Hmm. There should be no format vs. tiling restrictions on these
>platforms, so presumably a simple "return true" should cover it all.
>That does perhaps remove the usefulness of these functions for
>verifying that the format or modifier is supported at all
One of the reasons for changing to this current format-modifier lookup at all
was Kristian's approach was considered fragile. If for whatever reason formats
are added, or removed, we'll catch it here. Also, it maybe let's us do something
on cursor plane at some point (I don't actually know). So yeah, we can return
true, but I like that it's spelled out explicitly. Makes it easy to compare it
to the docs as well to make sure our code is correct.
The benefit is of course I can combine i965_mod_supported() with
i8xx_mod_supported()
I'm honestly fine with changing it as well, I just don't see a huge reason to
change it since I've already typed it up. I'll leave it to you.
Feel free to keep it. We can always change it later if it becomes too much
work to maintain the duplicated format lists (the function and the array).
Not that I really expect these lists to be all that volatile.
[ ] Yes, change it.
[ ] No, leave it.
>but I've been thinking that addfb should perhaps just iterate through the
>format and
Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel
On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:
> On 17-01-12 12:51:20, Ville Syrjälä wrote:
> >On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> >> This was based on a patch originally by Kristian. It has been modified
> >> pretty heavily to use the new callbacks from the previous patch.
> >>
> >> Cc: Kristian H. Kristensen
> >> Signed-off-by: Ben Widawsky
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 109
> >> ++-
> >> drivers/gpu/drm/i915/intel_sprite.c | 33 ++-
> >> 2 files changed, 137 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 8715b1083d1d..26f3a911b999 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
> >>DRM_FORMAT_XRGB,
> >> };
> >>
> >> +static const uint64_t i8xx_format_modifiers[] = {
> >> + I915_FORMAT_MOD_X_TILED,
> >
> >Did we want to list the linear modifier in these as well?
> >
>
> Yeah. My initial response was no, but yes. We should. I was using
> DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be
> defined
> in the array.
>
> >> + DRM_FORMAT_MOD_INVALID
> >> +};
> >> +
> >> /* Primary plane formats for gen >= 4 */
> >> static const uint32_t i965_primary_formats[] = {
> >>DRM_FORMAT_C8,
> >> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
> >>DRM_FORMAT_XBGR2101010,
> >> };
> >>
> >> +static const uint64_t i965_format_modifiers[] = {
> >> + I915_FORMAT_MOD_X_TILED,
> >> + DRM_FORMAT_MOD_INVALID
> >> +};
> >
> >We could just share the i8xx array. The name of the array should perhaps
> >be i9xx_format_modifiers[] in that case. That's sort of the naming
> >convention we've been left with for things that apply to more or less
> >all the platforms.
> >
>
> Got it thanks. This is a relic from Kristian's original patch which tied the
> modifiers to the formats in place. It made more sense there to have a separate
> i8xx
>
> >> +
> >> static const uint32_t skl_primary_formats[] = {
> >>DRM_FORMAT_C8,
> >>DRM_FORMAT_RGB565,
> >> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
> >>DRM_FORMAT_VYUY,
> >> };
> >>
> >> +static const uint64_t skl_format_modifiers[] = {
> >> + I915_FORMAT_MOD_Y_TILED,
> >
> >Yf missing? and linear
> >
>
> Yes, thanks. I'm kind of scared to add Yf to be honest :P
>
> >> + I915_FORMAT_MOD_X_TILED,
> >> + DRM_FORMAT_MOD_INVALID
> >> +};
> >> +
> >> /* Cursor formats */
> >> static const uint32_t intel_cursor_formats[] = {
> >>DRM_FORMAT_ARGB,
> >> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
> >>kfree(to_intel_plane(plane));
> >> }
> >>
> >> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> >> +{
> >> + if (modifier == DRM_FORMAT_MOD_NONE)
> >> + return true;
> >> +
> >> + switch (format) {
> >> + case DRM_FORMAT_C8:
> >> + case DRM_FORMAT_RGB565:
> >> + case DRM_FORMAT_XRGB1555:
> >> + case DRM_FORMAT_XRGB:
> >> + return modifier == I915_FORMAT_MOD_X_TILED;
> >> + default:
> >> + return false;
> >> + }
> >> +}
> >> +
> >> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> >> +{
> >> + switch (format) {
> >> + case DRM_FORMAT_C8:
> >> + case DRM_FORMAT_RGB565:
> >> + case DRM_FORMAT_XRGB:
> >> + case DRM_FORMAT_XBGR:
> >> + case DRM_FORMAT_XRGB2101010:
> >> + case DRM_FORMAT_XBGR2101010:
> >> + return modifier == I915_FORMAT_MOD_X_TILED;
> >> + default:
> >> + return false;
> >> + }
> >> +}
> >
> >Hmm. There should be no format vs. tiling restrictions on these
> >platforms, so presumably a simple "return true" should cover it all.
> >That does perhaps remove the usefulness of these functions for
> >verifying that the format or modifier is supported at all
>
> One of the reasons for changing to this current format-modifier lookup at all
> was Kristian's approach was considered fragile. If for whatever reason formats
> are added, or removed, we'll catch it here. Also, it maybe let's us do
> something
> on cursor plane at some point (I don't actually know). So yeah, we can return
> true, but I like that it's spelled out explicitly. Makes it easy to compare it
> to the docs as well to make sure our code is correct.
>
> The benefit is of course I can combine i965_mod_supported() with
> i8xx_mod_supported()
>
> I'm honestly fine with changing it as well, I just don't see a huge reason to
> change it since I've already typed it up. I'll leave it to you.
Feel free to keep it. We can always change it later if it becomes too much
work to maintain the duplicated format lists (the function and the array).
Not that I really expect these lists to be all that volatile.
>
> [ ] Yes, change it.
> [ ] No, leave it.
>
Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel
On 17-01-12 12:51:20, Ville Syrjälä wrote:
On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.
Cc: Kristian H. Kristensen
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 109 ++-
drivers/gpu/drm/i915/intel_sprite.c | 33 ++-
2 files changed, 137 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8715b1083d1d..26f3a911b999 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
DRM_FORMAT_XRGB,
};
+static const uint64_t i8xx_format_modifiers[] = {
+ I915_FORMAT_MOD_X_TILED,
Did we want to list the linear modifier in these as well?
Yeah. My initial response was no, but yes. We should. I was using
DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be defined
in the array.
+ DRM_FORMAT_MOD_INVALID
+};
+
/* Primary plane formats for gen >= 4 */
static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_C8,
@@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
};
+static const uint64_t i965_format_modifiers[] = {
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INVALID
+};
We could just share the i8xx array. The name of the array should perhaps
be i9xx_format_modifiers[] in that case. That's sort of the naming
convention we've been left with for things that apply to more or less
all the platforms.
Got it thanks. This is a relic from Kristian's original patch which tied the
modifiers to the formats in place. It made more sense there to have a separate
i8xx
+
static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint64_t skl_format_modifiers[] = {
+ I915_FORMAT_MOD_Y_TILED,
Yf missing? and linear
Yes, thanks. I'm kind of scared to add Yf to be honest :P
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* Cursor formats */
static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
}
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+ if (modifier == DRM_FORMAT_MOD_NONE)
+ return true;
+
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB1555:
+ case DRM_FORMAT_XRGB:
+ return modifier == I915_FORMAT_MOD_X_TILED;
+ default:
+ return false;
+ }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ return modifier == I915_FORMAT_MOD_X_TILED;
+ default:
+ return false;
+ }
+}
Hmm. There should be no format vs. tiling restrictions on these
platforms, so presumably a simple "return true" should cover it all.
That does perhaps remove the usefulness of these functions for
verifying that the format or modifier is supported at all
One of the reasons for changing to this current format-modifier lookup at all
was Kristian's approach was considered fragile. If for whatever reason formats
are added, or removed, we'll catch it here. Also, it maybe let's us do something
on cursor plane at some point (I don't actually know). So yeah, we can return
true, but I like that it's spelled out explicitly. Makes it easy to compare it
to the docs as well to make sure our code is correct.
The benefit is of course I can combine i965_mod_supported() with
i8xx_mod_supported()
I'm honestly fine with changing it as well, I just don't see a huge reason to
change it since I've already typed it up. I'll leave it to you.
[ ] Yes, change it.
[ ] No, leave it.
but I've been thinking that addfb should perhaps just iterate through the
format and modifier lists for every plane. Would avoid having to effectively
maintain the same lists in multiple places.
I don't quite follow this. Can you elaborate?
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ return modifier == I915_FORMAT_MOD_Y_TILED ||
+ m
Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel
On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> Cc: Kristian H. Kristensen
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_display.c | 109
> ++-
> drivers/gpu/drm/i915/intel_sprite.c | 33 ++-
> 2 files changed, 137 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8715b1083d1d..26f3a911b999 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
> DRM_FORMAT_XRGB,
> };
>
> +static const uint64_t i8xx_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,
Did we want to list the linear modifier in these as well?
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> /* Primary plane formats for gen >= 4 */
> static const uint32_t i965_primary_formats[] = {
> DRM_FORMAT_C8,
> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
> DRM_FORMAT_XBGR2101010,
> };
>
> +static const uint64_t i965_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_INVALID
> +};
We could just share the i8xx array. The name of the array should perhaps
be i9xx_format_modifiers[] in that case. That's sort of the naming
convention we've been left with for things that apply to more or less
all the platforms.
> +
> static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_C8,
> DRM_FORMAT_RGB565,
> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> +static const uint64_t skl_format_modifiers[] = {
> + I915_FORMAT_MOD_Y_TILED,
Yf missing? and linear
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> /* Cursor formats */
> static const uint32_t intel_cursor_formats[] = {
> DRM_FORMAT_ARGB,
> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
> kfree(to_intel_plane(plane));
> }
>
> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + if (modifier == DRM_FORMAT_MOD_NONE)
> + return true;
> +
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XRGB:
> + return modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
Hmm. There should be no format vs. tiling restrictions on these
platforms, so presumably a simple "return true" should cover it all.
That does perhaps remove the usefulness of these functions for
verifying that the format or modifier is supported at all, but I've been
thinking that addfb should perhaps just iterate through the format and
modifier lists for every plane. Would avoid having to effectively
maintain the same lists in multiple places.
> +
> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + return modifier == I915_FORMAT_MOD_Y_TILED ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == I915_FORMAT_MOD_X_TILED;
> + case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_YVYU:
> + case DRM_FORMAT_UYVY:
> + case DRM_FORMAT_VYUY:
IIRC on SKL the only restrictions should be that CCS modifiers are
limited to 8:8:8:8 formats only. Other modifiers should work
with any format.
> + default:
> + return false;
> + }
> +
> +}
> +
> +static bool intel_plane_format_mod_supported(struct drm_plane *plane,
> + uint32_t format,
> + uint64_t modifier)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> + if (modifier == DRM_FORMAT_MOD_NONE)
> + return true;
> +
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + if (WARN_ON(plane->type != DRM_PLANE_TYPE_PRIMARY &&
> + plane->type != DRM_PLANE_TYPE_OVERLAY))
> + return false;
> +
