Re: [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)
Hi,
On Thu, Dec 13, 2018 at 01:55:25PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties. E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal. Let's add a helper function that drivers can use to test that a
> userspace-provided LUT is valid and doesn't violate hardware
> requirements.
>
> v2:
> - Combine into a single helper that just takes a bitmask of the tests
>to apply. (Brian Starkey)
> - Add additional check (always performed) that LUT property blob size
>is always a multiple of the LUT entry size. (stolen from ARM driver)
>
> Cc: Uma Shankar
> Cc: Swati Sharma
> Cc: Brian Starkey
> Signed-off-by: Matt Roper
> Reviewed-by(v1): Brian Starkey
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 64
>
> include/drm/drm_color_mgmt.h | 5
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..5c2a2d228412 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -462,3 +462,67 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_color_properties);
> +
> +/**
> + * drm_color_lut_check - check validity of lookup table
> + * @lut: property blob containing LUT to check
> + * @tests: bitmask of tests to run
> + *
> + * Helper to check whether a userspace-provided lookup table is valid and
> + * satisfies additional hardware requirements. All table sizes should be a
> + * multiple of sizeof(struct drm_color_lut). Drivers pass a bitmask
> indicating
> + * which of the following additional tests should also be performed:
> + *
> + * "DRM_COLOR_LUT_EQUAL_CHANNELS":
> + * Checks whether the entries of a LUT all have equal values for the red,
> + * green, and blue channels. Intended for hardware that only accepts a
> + * single value per LUT entry and assumes that value applies to all three
> + * color components.
> + *
> + * "DRM_COLOR_LUT_INCREASING":
> + * Checks whether the entries of a LUT are always flat or increasing
> + * (never decreasing).
> + *
> + * Returns 0 on success, -EINVAL on failure.
> + */
> +int drm_color_lut_check(struct drm_property_blob *lut,
> + uint32_t tests)
> +{
> + struct drm_color_lut *entry;
> + int i;
> +
> + if (!lut)
> + return 0;
> +
> + if (lut->length % sizeof(struct drm_color_lut)) {
> + DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry
> size (%lu)\n",
> + lut->length, sizeof(struct drm_color_lut));
> + return -EINVAL;
> + }
> +
Isn't this already covered by drm_atomic_replace_property_blob_from_id ?
Other than that feel free to add:
Reviewed-by: Alexandru Gheorghe
> + if (!tests)
> + return 0;
> +
> + entry = lut->data;
> + for (i = 0; i < drm_color_lut_size(lut); i++) {
> + if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
> + if (entry[i].red != entry[i].blue ||
> + entry[i].red != entry[i].green) {
> + DRM_DEBUG_KMS("All LUT entries must have equal
> r/g/b\n");
> + return -EINVAL;
> + }
> + }
> +
> + if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
> + if (entry[i].red < entry[i - 1].red ||
> + entry[i].green < entry[i - 1].green ||
> + entry[i].blue < entry[i - 1].blue) {
> + DRM_DEBUG_KMS("LUT entries must never
> decrease.\n");
> + return -EINVAL;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_color_lut_check);
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..7de16f70bcc3 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
> +#define DRM_COLOR_LUT_INCREASING BIT(1)
> +int drm_color_lut_check(struct drm_property_blob *lut,
> + uint32_t tests);
> #endif
> --
> 2.14.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dr
Re: [PATCH v1] drm/arm: Delete redundant CONFIG_DRM_ARM
Hi James, On Wed, Dec 05, 2018 at 03:41:35AM +, james qian wang (Arm Technology China) wrote: > Delete redundant CONFIG_DRM_ARM, and add a menu "ARM devices" to subclass > ARM device drivers. > > Signed-off-by: James (Qian) Wang Reviewed-by: Alexandru Gheorghe > --- > drivers/gpu/drm/Makefile| 2 +- > drivers/gpu/drm/arm/Kconfig | 10 -- > 2 files changed, 5 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1fafc2f8e8f9..0df0a5a4cc82 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -51,7 +51,7 @@ obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ > obj-$(CONFIG_DRM)+= drm.o > obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o > obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o > -obj-$(CONFIG_DRM_ARM)+= arm/ > +obj-y+= arm/ > obj-$(CONFIG_DRM_TTM)+= ttm/ > obj-$(CONFIG_DRM_SCHED) += scheduler/ > obj-$(CONFIG_DRM_TDFX) += tdfx/ > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig > index 9a18e1bd57b4..f9f7761cb2f4 100644 > --- a/drivers/gpu/drm/arm/Kconfig > +++ b/drivers/gpu/drm/arm/Kconfig > @@ -1,13 +1,10 @@ > -config DRM_ARM > - bool > - help > - Choose this option to select drivers for ARM's devices > +# SPDX-License-Identifier: GPL-2.0 > +menu "ARM devices" > > config DRM_HDLCD > tristate "ARM HDLCD" > depends on DRM && OF && (ARM || ARM64) > depends on COMMON_CLK > - select DRM_ARM > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > help > @@ -29,7 +26,6 @@ config DRM_MALI_DISPLAY > tristate "ARM Mali Display Processor" > depends on DRM && OF && (ARM || ARM64) > depends on COMMON_CLK > - select DRM_ARM > select DRM_KMS_HELPER > select DRM_KMS_CMA_HELPER > select DRM_GEM_CMA_HELPER > @@ -40,3 +36,5 @@ config DRM_MALI_DISPLAY > of the hardware. > > If compiled as a module it will be called mali-dp. > + > +endmenu > -- > 2.17.1 -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/arm/malidp: Consider rotation memory requirement in case of AFBC framebuffer
Hi Ayan,
On Fri, Nov 09, 2018 at 10:37:19AM +, Ayan Halder wrote:
> Rotation memory for layers is shared with AFBC decoder block. Thus one needs
> to
> calculate rotation memory requirement in case of AFBC framebuffer. This is
> used later to verify if it can be sufficed by the hardware rotation memory
> availibility.
>
> Fixes: 66da13a ("drm/arm/malidp: Validate rotations for
> compressed/uncompressed framebuffers for each layer")
Reviewed-by: Alexandru Gheorghe
> Signed-off-by: Ayan Kumar halder
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index c9a6d3e..3f4dc64 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -470,7 +470,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> }
>
> ms->rotmem_size = 0;
> - if (state->rotation & MALIDP_ROTATED_MASK) {
> + if ((state->rotation & MALIDP_ROTATED_MASK) || fb->modifier) {
> int val;
>
> val = mp->hwdev->hw->rotmem_required(mp->hwdev, state->crtc_w,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/selftests: Fix build warning -Wframe-larger-than
It seems for some random configuration drm_device is bigger than 2048
bytes.
The fix is to make the mock objects static variables.
Bug reported by 0-DAY Kernel test infrastructure here:
https://lists.01.org/pipermail/kbuild-all/2018-November/054431.html
Fixes: 6ff3d9ffdcbb ("drm/selftests: Add tests for
drm_internal_framebuffer_create")
Signed-off-by: Alexandru Gheorghe
---
.../gpu/drm/selftests/test-drm_framebuffer.c | 30 ++-
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
index 3098435678af..a04d02dacce2 100644
--- a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
+++ b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
@@ -307,25 +307,27 @@ static struct drm_framebuffer *fb_create_mock(struct
drm_device *dev,
return ERR_PTR(-EINVAL);
}
+static struct drm_mode_config_funcs mock_config_funcs = {
+ .fb_create = fb_create_mock,
+};
+
+static struct drm_device mock_drm_device = {
+ .mode_config = {
+ .min_width = MIN_WIDTH,
+ .max_width = MAX_WIDTH,
+ .min_height = MIN_HEIGHT,
+ .max_height = MAX_HEIGHT,
+ .allow_fb_modifiers = true,
+ .funcs = &mock_config_funcs,
+ },
+};
+
static int execute_drm_mode_fb_cmd2(struct drm_mode_fb_cmd2 *r)
{
int buffer_created = 0;
struct drm_framebuffer *fb;
- struct drm_mode_config_funcs mock_config_funcs = {
- .fb_create = fb_create_mock,
- };
- struct drm_device mock_drm_device = {
- .mode_config = {
- .min_width = MIN_WIDTH,
- .max_width = MAX_WIDTH,
- .min_height = MIN_HEIGHT,
- .max_height = MAX_HEIGHT,
- .allow_fb_modifiers = true,
- .funcs = &mock_config_funcs,
- },
- .dev_private = &buffer_created
- };
+ mock_drm_device.dev_private = &buffer_created;
fb = drm_internal_framebuffer_create(&mock_drm_device, r, NULL);
return buffer_created;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Changes since v8:
- Fixed build on 32bits arm architectures, with:
- return DIV_ROUND_UP((u64)buffer_width * info->char_per_block[plane],
+ return DIV_ROUND_UP_ULL((u64)buffer_width * info->char_per_block[plane],
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 20 ++-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/drm_fourcc.c | 62
drivers/gpu/drm/drm_framebuffer.c| 6 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +-
include/drm/drm_fourcc.h | 61 ++-
6 files changed, 148 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..b07ab3f613e0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +108,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9b111e846847..8024524f0547 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1614,6 +1614,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1988,6 +1992,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+ WARN_ON
[RESEND v7 7/7] drm/selftests: Add tests for drm_internal_framebuffer_create
Add tests that verify that drm_internal_framebuffer_create creates
buffers correctly by creating a dummy drm_device with a mock function
for the fb_create callback.
To decide if a buffer has been created or not it just checks if
fb_create callback has been called for the particular drm_mode_fb_cmd2
that's being tested.
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/selftests/Makefile| 2 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 1 +
.../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++
.../drm/selftests/test-drm_modeset_common.h | 1 +
4 files changed, 347 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 07b4f88b422a..383d8d6c5847 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,4 +1,4 @@
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
- test-drm_format.o
+ test-drm_format.o test-drm_framebuffer.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 4e203ac8c134..92601defd8f6 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -10,3 +10,4 @@ selftest(check_plane_state, igt_check_plane_state)
selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
+selftest(check_drm_framebuffer_create, igt_check_drm_framebuffer_create)
diff --git a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
new file mode 100644
index ..3098435678af
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_framebuffer functions
+ */
+
+#include
+#include "../drm_crtc_internal.h"
+
+#include "test-drm_modeset_common.h"
+
+#define MIN_WIDTH 4
+#define MAX_WIDTH 4096
+#define MIN_HEIGHT 4
+#define MAX_HEIGHT 4096
+
+struct drm_framebuffer_test {
+ int buffer_created;
+ struct drm_mode_fb_cmd2 cmd;
+ const char *name;
+};
+
+static struct drm_framebuffer_test createbuffer_tests[] = {
+{ .buffer_created = 1, .name = "ABGR normal sizes",
+ .cmd = { .width = 600, .height = 600, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * 600, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR max sizes",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR pitch greater than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH + 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR pitch less than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH - 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid width",
+ .cmd = { .width = MAX_WIDTH + 1, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * (MAX_WIDTH + 1), 0, 0
},
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid buffer handle",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 0, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "No pixel format",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format = 0,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Width 0",
+ .cmd = { .width = 0, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Height 0",
+ .cmd = { .width = MAX_WIDTH, .height = 0, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Out of bound height * pitch
combination",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .
[RESEND v7 3/7] drm: mali-dp: Enable Mali-DP tiled buffer formats
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 28 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7aad7dd80d8c..b9bed1138fa3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -77,12 +77,18 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
- { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
+ { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
};
+static const struct malidp_format_id malidp650_de_formats[] = {
+ MALIDP_COMMON_FORMATS,
+ { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
+};
+
static const struct malidp_layer malidp500_layers[] = {
/* id, base address, fb pointer address base, stride offset,
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
@@ -630,6 +636,8 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_BGR565:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_X0L0:
+ case DRM_FORMAT_X0L2:
bytes_per_col = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
@@ -905,8 +913,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
- .pixel_formats = malidp550_de_formats,
- .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
+ .pixel_formats = malidp650_de_formats,
+ .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 837a24d56675..c9a6d3e0cada 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -398,6 +398,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
struct drm_framebuffer *fb;
u16 pixel_alpha = state->pixel_blend_mode;
int i, ret;
+ unsigned int block_w, block_h;
if (!state->crtc || !state->fb)
return 0;
@@ -413,13 +414,26 @@ static int malidp_de_plane_check(struct drm_plane *plane,
ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if (fb->pitches[i] & (alignment - 1)) {
+
+ if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
}
}
+ block_w = drm_format_info_block_width(fb->format, 0);
+ block_h = drm_format_info_block_height(fb->format, 0);
+ if (fb->width % block_w || fb->height % block_h) {
+ DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
+ return -EINVAL;
+ }
+ if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
+ DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
+ return -EINVAL;
+ }
+
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
@@ -492,10 +506,18 @@ static void malidp_de_set_plane_pitches(struct
malidp_plane *mp,
num_strides = (mp->hwdev->hw->features &
MALIDP_DEVICE_LV_HAS_3_STRIDES) ? 3 : 2;
- for (i = 0; i < num_strides; ++i)
- malidp_hw_write(mp->hwdev, pitches[i],
+ /*
+* The drm convention for pitch is that it needs to cover width * cpp,
+* but our hardware wants the pitch/stride to cover all rows included
+* in a tile.
+*/
+ for (i = 0; i < num_strides; ++i) {
+ unsigned int blo
[RESEND v7 4/7] drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This had been discussed here.
[1]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_framebuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 6aca8a1ccdb6..167c1c4544af 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -195,8 +195,14 @@ static int framebuffer_check(struct drm_device *dev,
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
+ unsigned int block_size = info->char_per_block[i];
u64 min_pitch = drm_format_info_min_pitch(info, i, width);
+ if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
+ DRM_DEBUG_KMS("Format requires non-linear modifier for
plane %d\n", i);
+ return -EINVAL;
+ }
+
if (!r->handles[i]) {
DRM_DEBUG_KMS("no buffer object handle for plane %d\n",
i);
return -EINVAL;
@@ -208,7 +214,7 @@ static int framebuffer_check(struct drm_device *dev,
if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
UINT_MAX)
return -ERANGE;
- if (r->pitches[i] < min_pitch) {
+ if (block_size && r->pitches[i] < min_pitch) {
DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
return -EINVAL;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 5/7] drm/selftests: Add tests for drm_format_info* helpers
Add selftests for the following newly added functions:
- drm_format_info_block_width
- drm_format_info_block_height
- drm_format_info_min_pitch
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_format.c | 280 ++
.../drm/selftests/test-drm_modeset_common.h | 3 +
4 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 7e6581921da0..07b4f88b422a 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,3 +1,4 @@
-test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o
+test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
+ test-drm_format.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 9771290ed228..4e203ac8c134 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -7,3 +7,6 @@
* Tests are executed in order by igt/drm_selftests_helper
*/
selftest(check_plane_state, igt_check_plane_state)
+selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
+selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
+selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
diff --git a/drivers/gpu/drm/selftests/test-drm_format.c
b/drivers/gpu/drm/selftests/test-drm_format.c
new file mode 100644
index ..c5e212afa27a
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_format.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_format functions
+ */
+
+#define pr_fmt(fmt) "drm_format: " fmt
+
+#include
+#include
+
+#include
+
+#include "test-drm_modeset_common.h"
+
+int igt_check_drm_format_block_width(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_width(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 3) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test a tiled format */
+ info = drm_format_info(DRM_FORMAT_X0L0);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 2);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ return 0;
+}
+
+int igt_check_drm_format_block_height(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_height(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(d
[RESEND v7 6/7] drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled
If we want to be able to write drmselftests for non-static core functions that are not intended to be used by drivers we need this functions to be exported. This adds a macro that is tied of CONFIG_DRM_DEBUG_SELFTEST, and uses that to export drm_internal_framebuffer_create, in order for subsequent patches to be able to test it. Signed-off-by: Alexandru Gheorghe Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_framebuffer.c | 1 + include/drm/drmP.h| 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 167c1c4544af..fcaea8f50513 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -323,6 +323,7 @@ drm_internal_framebuffer_create(struct drm_device *dev, return fb; } +EXPORT_SYMBOL_FOR_TESTS_ONLY(drm_internal_framebuffer_create); /** * drm_mode_addfb2 - add an FB to the graphics configuration diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 05350424a4d3..514beb2d483a 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -110,4 +110,10 @@ static inline bool drm_can_sleep(void) return true; } +#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE) +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x) +#else +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) +#endif + #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 1/7] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 20 ++-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/drm_fourcc.c | 62
drivers/gpu/drm/drm_framebuffer.c| 6 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +-
include/drm/drm_fourcc.h | 61 ++-
6 files changed, 148 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..b07ab3f613e0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +108,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9b111e846847..8024524f0547 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1614,6 +1614,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1988,6 +1992,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+ WARN_ON((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1));
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
[RESEND v7 2/7] drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Reviewed-by: Brian Starkey
Reviewed-by: Daniel Vetter
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 00c96dbdcad5..aaae6152ee5e 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -225,6 +225,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0cd40ebfa1b1..e7e48f1f4a74 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -152,6 +152,20 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/*
+ * packed YCbCr420 2x2 tiled formats
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
+ */
+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
+
+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
+/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_X0L2fourcc_code('X', '0', 'L', '2')
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 0/7] Add method to describe tile/bit_level_packed formats
Basically, just a resend before I merge these patches in drm-misc-next. Changes since v6: - Collected Reviewed-by. - Fixed author, seems dim it's not smart enough to know "Alexandru Gheorghe" is the same with Alexandru-Cosmin Gheorghe :). - Fixed conflicts against latest drm-misc-next. - Dropped the patches that added the fourccs for AFBC only, that should be merged when driver implementation is ready. Alexandru Gheorghe (7): drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info drm/fourcc: Add fourcc for Mali linear tiled formats drm: mali-dp: Enable Mali-DP tiled buffer formats drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0 drm/selftests: Add tests for drm_format_info* helpers drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled drm/selftests: Add tests for drm_internal_framebuffer_create drivers/gpu/drm/arm/malidp_hw.c | 14 +- drivers/gpu/drm/arm/malidp_planes.c | 28 +- drivers/gpu/drm/drm_fb_cma_helper.c | 20 +- drivers/gpu/drm/drm_fb_helper.c | 6 + drivers/gpu/drm/drm_fourcc.c | 74 drivers/gpu/drm/drm_framebuffer.c | 13 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +- drivers/gpu/drm/selftests/Makefile| 3 +- .../gpu/drm/selftests/drm_modeset_selftests.h | 4 + drivers/gpu/drm/selftests/test-drm_format.c | 280 ++ .../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++ .../drm/selftests/test-drm_modeset_common.h | 4 + include/drm/drmP.h| 6 + include/drm/drm_fourcc.h | 61 +++- include/uapi/drm/drm_fourcc.h | 14 + 15 files changed, 857 insertions(+), 16 deletions(-) create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/9] drm: mali-dp: Enable Mali-DP tiled buffer formats
Hi,
Liviu, can I merge this through drm-misc-next.
On Mon, Oct 29, 2018 at 05:14:38PM +, Alexandru-Cosmin Gheorghe wrote:
> Enable the following formats
> - DRM_FORMAT_X0L0: DP650
> - DRM_FORMAT_X0L2: DP550, DP650
>
> Reviewed-by: Brian Starkey
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
> drivers/gpu/drm/arm/malidp_planes.c | 28 +---
> 2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 7aad7dd80d8c..b9bed1138fa3 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -77,12 +77,18 @@ static const struct malidp_format_id
> malidp500_de_formats[] = {
> { DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
> { DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
> { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
> }, \
> - { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
> + { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
> + { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
>
> static const struct malidp_format_id malidp550_de_formats[] = {
> MALIDP_COMMON_FORMATS,
> };
>
> +static const struct malidp_format_id malidp650_de_formats[] = {
> + MALIDP_COMMON_FORMATS,
> + { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
> +};
> +
> static const struct malidp_layer malidp500_layers[] = {
> /* id, base address, fb pointer address base, stride offset,
>* yuv2rgb matrix offset, mmu control register offset,
> rotation_features
> @@ -630,6 +636,8 @@ static int malidp550_rotmem_required(struct
> malidp_hw_device *hwdev, u16 w, u16
> case DRM_FORMAT_BGR565:
> case DRM_FORMAT_UYVY:
> case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_X0L0:
> + case DRM_FORMAT_X0L2:
> bytes_per_col = 32;
> break;
> /* 16 lines at 1.5 bytes per pixel */
> @@ -905,8 +913,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES]
> = {
> MALIDP550_DC_IRQ_SE,
> .vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
> },
> - .pixel_formats = malidp550_de_formats,
> - .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
> + .pixel_formats = malidp650_de_formats,
> + .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
> .bus_align_bytes = 16,
> },
> .query_hw = malidp650_query_hw,
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 837a24d56675..c9a6d3e0cada 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -398,6 +398,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> struct drm_framebuffer *fb;
> u16 pixel_alpha = state->pixel_blend_mode;
> int i, ret;
> + unsigned int block_w, block_h;
>
> if (!state->crtc || !state->fb)
> return 0;
> @@ -413,13 +414,26 @@ static int malidp_de_plane_check(struct drm_plane
> *plane,
> ms->n_planes = fb->format->num_planes;
> for (i = 0; i < ms->n_planes; i++) {
> u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
> - if (fb->pitches[i] & (alignment - 1)) {
> +
> + if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
> i))
> + & (alignment - 1)) {
> DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
> fb->pitches[i], i);
> return -EINVAL;
> }
> }
>
> + block_w = drm_format_info_block_width(fb->format, 0);
> + block_h = drm_format_info_block_height(fb->format, 0);
> + if (fb->width % block_w || fb->height % block_h) {
> + DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
> tile sizes");
> + return -EINVAL;
> + }
> + if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
> + DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
> sizes");
> + return -EINVAL;
> + }
> +
> if ((state->crtc_w > mp->hwdev->max_line_size) ||
> (state->crtc_h > mp->hwdev->
[PATCH v6 4/9] drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This had been discussed here.
[1]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_framebuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 6aca8a1ccdb6..167c1c4544af 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -195,8 +195,14 @@ static int framebuffer_check(struct drm_device *dev,
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
+ unsigned int block_size = info->char_per_block[i];
u64 min_pitch = drm_format_info_min_pitch(info, i, width);
+ if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
+ DRM_DEBUG_KMS("Format requires non-linear modifier for
plane %d\n", i);
+ return -EINVAL;
+ }
+
if (!r->handles[i]) {
DRM_DEBUG_KMS("no buffer object handle for plane %d\n",
i);
return -EINVAL;
@@ -208,7 +214,7 @@ static int framebuffer_check(struct drm_device *dev,
if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
UINT_MAX)
return -ERANGE;
- if (r->pitches[i] < min_pitch) {
+ if (block_size && r->pitches[i] < min_pitch) {
DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
return -EINVAL;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/9] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V)
[PATCH v6 7/9] drm/selftests: Add tests for drm_format_info* helpers
Add selftests for the following newly added functions:
- drm_format_info_block_width
- drm_format_info_block_height
- drm_format_info_min_pitch
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_format.c | 290 ++
.../drm/selftests/test-drm_modeset_common.h | 3 +
4 files changed, 298 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 7e6581921da0..07b4f88b422a 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,3 +1,4 @@
-test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o
+test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
+ test-drm_format.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 9771290ed228..4e203ac8c134 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -7,3 +7,6 @@
* Tests are executed in order by igt/drm_selftests_helper
*/
selftest(check_plane_state, igt_check_plane_state)
+selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
+selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
+selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
diff --git a/drivers/gpu/drm/selftests/test-drm_format.c
b/drivers/gpu/drm/selftests/test-drm_format.c
new file mode 100644
index ..5abfd5e28d7d
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_format.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_format functions
+ */
+
+#define pr_fmt(fmt) "drm_format: " fmt
+
+#include
+#include
+
+#include
+
+#include "test-drm_modeset_common.h"
+
+int igt_check_drm_format_block_width(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_width(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 3) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test a tiled format */
+ info = drm_format_info(DRM_FORMAT_X0L0);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 2);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ return 0;
+}
+
+int igt_check_drm_format_block_height(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_height(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(
[PATCH v6 9/9] drm/selftests: Add tests for drm_internal_framebuffer_create
Add tests that verify that drm_internal_framebuffer_create creates
buffers correctly by creating a dummy drm_device with a mock function
for the fb_create callback.
To decide if a buffer has been created or not it just checks if
fb_create callback has been called for the particular drm_mode_fb_cmd2
that's being tested.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/selftests/Makefile| 2 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 1 +
.../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++
.../drm/selftests/test-drm_modeset_common.h | 1 +
4 files changed, 347 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 07b4f88b422a..383d8d6c5847 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,4 +1,4 @@
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
- test-drm_format.o
+ test-drm_format.o test-drm_framebuffer.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 4e203ac8c134..92601defd8f6 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -10,3 +10,4 @@ selftest(check_plane_state, igt_check_plane_state)
selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
+selftest(check_drm_framebuffer_create, igt_check_drm_framebuffer_create)
diff --git a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
new file mode 100644
index ..3098435678af
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_framebuffer functions
+ */
+
+#include
+#include "../drm_crtc_internal.h"
+
+#include "test-drm_modeset_common.h"
+
+#define MIN_WIDTH 4
+#define MAX_WIDTH 4096
+#define MIN_HEIGHT 4
+#define MAX_HEIGHT 4096
+
+struct drm_framebuffer_test {
+ int buffer_created;
+ struct drm_mode_fb_cmd2 cmd;
+ const char *name;
+};
+
+static struct drm_framebuffer_test createbuffer_tests[] = {
+{ .buffer_created = 1, .name = "ABGR normal sizes",
+ .cmd = { .width = 600, .height = 600, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * 600, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR max sizes",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR pitch greater than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH + 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR pitch less than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH - 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid width",
+ .cmd = { .width = MAX_WIDTH + 1, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * (MAX_WIDTH + 1), 0, 0
},
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid buffer handle",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 0, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "No pixel format",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format = 0,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Width 0",
+ .cmd = { .width = 0, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Height 0",
+ .cmd = { .width = MAX_WIDTH, .height = 0, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Out of bound height * pitch
combination",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .offsets = { UINT_MAX - 1, 0,
[PATCH v6 3/9] drm: mali-dp: Enable Mali-DP tiled buffer formats
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 28 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7aad7dd80d8c..b9bed1138fa3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -77,12 +77,18 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
- { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
+ { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
};
+static const struct malidp_format_id malidp650_de_formats[] = {
+ MALIDP_COMMON_FORMATS,
+ { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
+};
+
static const struct malidp_layer malidp500_layers[] = {
/* id, base address, fb pointer address base, stride offset,
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
@@ -630,6 +636,8 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_BGR565:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_X0L0:
+ case DRM_FORMAT_X0L2:
bytes_per_col = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
@@ -905,8 +913,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
- .pixel_formats = malidp550_de_formats,
- .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
+ .pixel_formats = malidp650_de_formats,
+ .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 837a24d56675..c9a6d3e0cada 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -398,6 +398,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
struct drm_framebuffer *fb;
u16 pixel_alpha = state->pixel_blend_mode;
int i, ret;
+ unsigned int block_w, block_h;
if (!state->crtc || !state->fb)
return 0;
@@ -413,13 +414,26 @@ static int malidp_de_plane_check(struct drm_plane *plane,
ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if (fb->pitches[i] & (alignment - 1)) {
+
+ if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
}
}
+ block_w = drm_format_info_block_width(fb->format, 0);
+ block_h = drm_format_info_block_height(fb->format, 0);
+ if (fb->width % block_w || fb->height % block_h) {
+ DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
+ return -EINVAL;
+ }
+ if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
+ DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
+ return -EINVAL;
+ }
+
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
@@ -492,10 +506,18 @@ static void malidp_de_set_plane_pitches(struct
malidp_plane *mp,
num_strides = (mp->hwdev->hw->features &
MALIDP_DEVICE_LV_HAS_3_STRIDES) ? 3 : 2;
- for (i = 0; i < num_strides; ++i)
- malidp_hw_write(mp->hwdev, pitches[i],
+ /*
+* The drm convention for pitch is that it needs to cover width * cpp,
+* but our hardware wants the pitch/stride to cover all rows included
+* in a tile.
+*/
+ for (i = 0; i < num_strides; ++i) {
+ unsigned int blo
[PATCH v6 2/9] drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index a843a5fc8dbf..b2ca0c526c3c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -228,6 +228,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 242a1d72a1ce..b82f528202f7 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -152,6 +152,20 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/*
+ * packed YCbCr420 2x2 tiled formats
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
+ */
+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
+
+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
+/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_X0L2fourcc_code('X', '0', 'L', '2')
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/9] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fb_cma_helper.c | 20 ++-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/drm_fourcc.c | 62
drivers/gpu/drm/drm_framebuffer.c| 6 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +-
include/drm/drm_fourcc.h | 61 ++-
6 files changed, 148 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..b07ab3f613e0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +108,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9b111e846847..8024524f0547 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1614,6 +1614,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1988,6 +1992,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+ WARN_ON((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1));
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
info->var.yres_virtual =
[PATCH v6 8/9] drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled
If we want to be able to write drmselftests for non-static core functions that are not intended to be used by drivers we need this functions to be exported. This adds a macro that is tied of CONFIG_DRM_DEBUG_SELFTEST, and uses that to export drm_internal_framebuffer_create, in order for subsequent patches to be able to test it. Signed-off-by: Alexandru Gheorghe --- drivers/gpu/drm/drm_framebuffer.c | 1 + include/drm/drmP.h| 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 167c1c4544af..fcaea8f50513 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -323,6 +323,7 @@ drm_internal_framebuffer_create(struct drm_device *dev, return fb; } +EXPORT_SYMBOL_FOR_TESTS_ONLY(drm_internal_framebuffer_create); /** * drm_mode_addfb2 - add an FB to the graphics configuration diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 05350424a4d3..514beb2d483a 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -110,4 +110,10 @@ static inline bool drm_can_sleep(void) return true; } +#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE) +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x) +#else +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) +#endif + #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 6/9] drm/afbc: Add AFBC modifier usage documentation
From: Brian Starkey AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- Documentation/gpu/afbc.rst| 233 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 238 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index ..922d955da192 --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,233 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) +
[PATCH v6 0/9] Add method to describe tile/bit_level_packed formats
Changes since v5: - Added selftests for drm_internal_framebuffer_create - Added a macro to export internal function only when DRM_DEBUG_SELFTEST is enabled, suggested by Daniel Vetter, here [5]. - Cosmetic fixes suggested by Brian Starkey. - Rebased against drm-misc-next Changes since v4: - Rebased selftests on latest drm-misc-next Changes since v3: - added an utility function that computes the minimum pitch. - switched drm_format_info to in-line member documentation. - Cleanup/Improved the kernel doc. - Added selftests for: drm_format_info* helpers. There has been some discussion about extending drm core to handle linear tile formats, in the series sent by me here [1] and how to handle formats that are intended to be used just with modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC here [3] and [4]. Hence, this big-merged series: Patch 1: Just a preparation patch that converts the drm_format_info kerneldoc to in-line documentation. Patches 2-4: handle tiled formats both in core and in malidp driver, this is done by extending drm_format_info with three new fields char_per_block, block_w, block_h and consistently handle in the generic code paths, both linear tiled formats and normal formats. What's different from [1] is the interpretation of pitch for tile formats which has been kept to be the same as for the other formats: pitch = average_chars_per_pixel * width. Patches 5-7: Introduce the YUV AFBC formats, the only thing noteworthy here is that cpp/char_per_block are set to 0 for formats where it's mandatory to be used together with a non-linear modifier and then that is used to bypass pitch check in framebuffer_check for formats that have cpp/char_per_block set to 0. Patches 8-9: A small fix for test-drm-helper module and adds self tests for drm_format_info* helpers. For the other touched functions we need a bit more infrastructure to be able to unittest/selftest them, since they need a stub drm_device and drm_file. As a side note, igt master branch doesn't seem to be using test-drm-helper.ko, so I just tested by loading/unloading the module manually. [1] https://lists.freedesktop.org/archives/dri-devel/2018-September/188245.html [2] https://lists.freedesktop.org/archives/dri-devel/2018-September/189620.html [3] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true [4] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-14&show_html=true [5] https://www.spinics.net/lists/dri-devel/msg193422.html v5: https://www.spinics.net/lists/dri-devel/msg193384.html Alexandru Gheorghe (7): drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info drm/fourcc: Add fourcc for Mali linear tiled formats drm: mali-dp: Enable Mali-DP tiled buffer formats drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0 drm/selftests: Add tests for drm_format_info* helpers drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled drm/selftests: Add tests for drm_internal_framebuffer_create Brian Starkey (2): drm/fourcc: Add AFBC yuv fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst| 233 Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + drivers/gpu/drm/arm/malidp_hw.c | 14 +- drivers/gpu/drm/arm/malidp_planes.c | 28 +- drivers/gpu/drm/drm_fb_cma_helper.c | 20 +- drivers/gpu/drm/drm_fb_helper.c | 6 + drivers/gpu/drm/drm_fourcc.c | 87 + drivers/gpu/drm/drm_framebuffer.c | 13 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +- drivers/gpu/drm/selftests/Makefile| 3 +- .../gpu/drm/selftests/drm_modeset_selftests.h | 4 + drivers/gpu/drm/selftests/test-drm_format.c | 290 +++ .../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++ .../drm/selftests/test-drm_modeset_common.h | 4 + include/drm/drmP.h| 6 + include/drm/drm_fourcc.h | 61 +++- include/uapi/drm/drm_fourcc.h | 31 ++ 18 files changed, 1132 insertions(+), 16 deletions(-) create mode 100644 Documentation/gpu/afbc.rst create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/21] drm/doc: kerneldoc for quirk_addfb_prefer_xbgr_30bpp
Hi,
Daniel,
On Thu, Oct 04, 2018 at 10:24:46PM +0200, Daniel Vetter wrote:
> Shuts up warning noise.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alexandru Gheorghe
> ---
> include/drm/drm_mode_config.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 928e4172a0bb..d643d268693e 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -809,6 +809,13 @@ struct drm_mode_config {
>
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
> +
> + /**
> + * @quirk_addfb_prefer_xbgr_30bpp:
> + *
> + * Special hack for legacy ADDFB to keep nouveau userspace happy. Should
> + * only ever be set by the nouveau kernel driver.
> + */
> bool quirk_addfb_prefer_xbgr_30bpp;
>
> /**
> --
> 2.19.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 9/9] drm/selftests: Add tests for drm_format_info* helpers
On Fri, Oct 19, 2018 at 05:29:15PM +0200, Daniel Vetter wrote:
> On Fri, Oct 19, 2018 at 11:57:52AM +0100, Alexandru Gheorghe wrote:
> > Add selftests for the following newly added functions:
> > - drm_format_info_block_width
> > - drm_format_info_block_height
> > - drm_format_info_min_pitch
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/selftests/Makefile| 3 +-
> > .../gpu/drm/selftests/drm_modeset_selftests.h | 3 +
> > drivers/gpu/drm/selftests/test-drm_format.c | 290 ++
> > .../drm/selftests/test-drm_modeset_common.h | 3 +
> > 4 files changed, 298 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c
> >
> > diff --git a/drivers/gpu/drm/selftests/Makefile
> > b/drivers/gpu/drm/selftests/Makefile
> > index 7e6581921da0..07b4f88b422a 100644
> > --- a/drivers/gpu/drm/selftests/Makefile
> > +++ b/drivers/gpu/drm/selftests/Makefile
> > @@ -1,3 +1,4 @@
> > -test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o
> > +test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
> > + test-drm_format.o
> >
> > obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
> > diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> > b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> > index 9771290ed228..4e203ac8c134 100644
> > --- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> > +++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> > @@ -7,3 +7,6 @@
> > * Tests are executed in order by igt/drm_selftests_helper
> > */
> > selftest(check_plane_state, igt_check_plane_state)
> > +selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
> > +selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
> > +selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
> > diff --git a/drivers/gpu/drm/selftests/test-drm_format.c
> > b/drivers/gpu/drm/selftests/test-drm_format.c
> > new file mode 100644
> > index ..5abfd5e28d7d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/selftests/test-drm_format.c
> > @@ -0,0 +1,290 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Test cases for the drm_format functions
> > + */
> > +
> > +#define pr_fmt(fmt) "drm_format: " fmt
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "test-drm_modeset_common.h"
> > +
> > +int igt_check_drm_format_block_width(void *ignored)
> > +{
> > + const struct drm_format_info *info = NULL;
> > +
> > + /* Test invalid arguments */
> > + FAIL_ON(drm_format_info_block_width(info, 0) != 0);
> > + FAIL_ON(drm_format_info_block_width(info, -1) != 0);
> > + FAIL_ON(drm_format_info_block_width(info, 1) != 0);
> > +
> > + /* Test 1 plane format */
> > + info = drm_format_info(DRM_FORMAT_XRGB);
> > + FAIL_ON(!info);
> > + FAIL_ON(drm_format_info_block_width(info, 0) != 1);
> > + FAIL_ON(drm_format_info_block_width(info, 1) != 0);
> > + FAIL_ON(drm_format_info_block_width(info, -1) != 0);
> > +
> > + /* Test 2 planes format */
> > + info = drm_format_info(DRM_FORMAT_NV12);
> > + FAIL_ON(!info);
> > + FAIL_ON(drm_format_info_block_width(info, 0) != 1);
> > + FAIL_ON(drm_format_info_block_width(info, 1) != 1);
> > + FAIL_ON(drm_format_info_block_width(info, 2) != 0);
> > + FAIL_ON(drm_format_info_block_width(info, -1) != 0);
> > +
> > + /* Test 3 planes format */
> > + info = drm_format_info(DRM_FORMAT_YUV422);
> > + FAIL_ON(!info);
> > + FAIL_ON(drm_format_info_block_width(info, 0) != 1);
> > + FAIL_ON(drm_format_info_block_width(info, 1) != 1);
> > + FAIL_ON(drm_format_info_block_width(info, 2) != 1);
> > + FAIL_ON(drm_format_info_block_width(info, 3) != 0);
> > + FAIL_ON(drm_format_info_block_width(info, -1) != 0);
> > +
> > + /* Test a tiled format */
> > + info = drm_format_info(DRM_FORMAT_X0L0);
> > + FAIL_ON(!info);
> > + FAIL_ON(drm_format_info_block_width(info, 0) != 2);
> > + FAIL_ON(drm_format_info_block_width(info, 1) != 0);
> > + FAIL_ON(drm_format_info_block_width(info, -1) != 0);
> > +
> > + return 0;
> > +}
> > +
> > +int igt_check_drm_format_block_height(void *ignored)
> > +{
> > + const struct drm_format_info *info = NULL;
> > +
> > + /* Test invalid arguments */
> > + FAIL_ON(drm_format_info_block_height(info, 0) != 0);
> > + FAIL_ON(drm_format_info_block_height(info, -1) != 0);
> > + FAIL_ON(drm_format_info_block_height(info, 1) != 0);
> > +
> > + /* Test 1 plane format */
> > + info = drm_format_info(DRM_FORMAT_XRGB);
> > + FAIL_ON(!info);
> > + FAIL_ON(drm_format_info_block_height(info, 0) != 1);
> > + FAIL_ON(drm_format_info_block_height(info, 1) != 0);
> > + FAIL_ON(drm_format_info_block_height(info, -1) != 0);
> > +
> > + /* Test 2 planes format */
> > + info = drm_format_info(DRM_FORMAT_NV12);
> > + FAIL_ON(!info);
> > + FAIL_ON(drm_format_info_block_
Re: [PATCH v5 5/9] drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0
On Fri, Oct 19, 2018 at 02:21:46PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Fri, Oct 19, 2018 at 11:57:48AM +0100, Alexandru Gheorghe wrote:
> >For formats that are supported only with non-linear modifiers it
> >doesn't make to much sense to define cpp or char_per_block, so that
> >will be set to 0.
> >
> >This patch adds a restriction to force having a modifier attached when
> >cpp/char_per_block is 0, and to bypass checking the pitch restriction.
> >
> >This had been discussed here.
> >[1]
> >https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true
> >
> >Signed-off-by: Alexandru Gheorghe
> >---
> >drivers/gpu/drm/drm_framebuffer.c | 7 ++-
> >1 file changed, 6 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_framebuffer.c
> >b/drivers/gpu/drm/drm_framebuffer.c
> >index 6aca8a1ccdb6..e346d0ad92e0 100644
> >--- a/drivers/gpu/drm/drm_framebuffer.c
> >+++ b/drivers/gpu/drm/drm_framebuffer.c
> >@@ -195,8 +195,13 @@ static int framebuffer_check(struct drm_device *dev,
> > for (i = 0; i < info->num_planes; i++) {
> > unsigned int width = fb_plane_width(r->width, info, i);
> > unsigned int height = fb_plane_height(r->height, info, i);
> >+unsigned int block_size = info->char_per_block[i];
> > u64 min_pitch = drm_format_info_min_pitch(info, i, width);
> >
> >+if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
> >+DRM_DEBUG_KMS("Format requires non-linear modifier for
> >plane %d\n", i);
> >+return -EINVAL;
> >+}
>
> You could probably move that blank like from Patch 2 to here ;-)
> Otherwise LGTM:
I blame rebase :)
>
> Reviewed By: Brian Starkey
>
> > if (!r->handles[i]) {
> > DRM_DEBUG_KMS("no buffer object handle for plane %d\n",
> > i);
> > return -EINVAL;
> >@@ -208,7 +213,7 @@ static int framebuffer_check(struct drm_device *dev,
> > if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
> > UINT_MAX)
> > return -ERANGE;
> >
> >-if (r->pitches[i] < min_pitch) {
> >+if (block_size && r->pitches[i] < min_pitch) {
> > DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
> > r->pitches[i], i);
> > return -EINVAL;
> > }
> >--
> >2.18.0
> >
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/9] drm: mali-dp: Enable Mali-DP tiled buffer formats
On Fri, Oct 19, 2018 at 02:17:22PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Fri, Oct 19, 2018 at 11:57:47AM +0100, Alexandru Gheorghe wrote:
> >Enable the following formats
> >- DRM_FORMAT_X0L0: DP650
> >- DRM_FORMAT_X0L2: DP550, DP650
> >
> >Signed-off-by: Alexandru Gheorghe
>
> A couple of suggestions below, but with or without you can add my
> r-b.
Will address them in the next version.
>
> >---
> >drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
> >drivers/gpu/drm/arm/malidp_planes.c | 23 +--
> >2 files changed, 32 insertions(+), 5 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> >b/drivers/gpu/drm/arm/malidp_hw.c
> >index c94a4422e0e9..e01fc0e5b503 100644
> >--- a/drivers/gpu/drm/arm/malidp_hw.c
> >+++ b/drivers/gpu/drm/arm/malidp_hw.c
> >@@ -77,12 +77,18 @@ static const struct malidp_format_id
> >malidp500_de_formats[] = {
> > { DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
> > { DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
> > { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
> > }, \
> >-{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
> >+{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
> >+{ DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
> >
> >static const struct malidp_format_id malidp550_de_formats[] = {
> > MALIDP_COMMON_FORMATS,
> >};
> >
> >+static const struct malidp_format_id malidp650_de_formats[] = {
> >+MALIDP_COMMON_FORMATS,
> >+{ DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
> >+};
> >+
> >static const struct malidp_layer malidp500_layers[] = {
> > { DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
> > MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB },
> > { DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
> > MALIDP_DE_LG_STRIDE, 0 },
> >@@ -595,6 +601,8 @@ static int malidp550_rotmem_required(struct
> >malidp_hw_device *hwdev, u16 w, u16
> > case DRM_FORMAT_BGR565:
> > case DRM_FORMAT_UYVY:
> > case DRM_FORMAT_YUYV:
> >+case DRM_FORMAT_X0L0:
> >+case DRM_FORMAT_X0L2:
> > bytes_per_col = 32;
> > break;
> > /* 16 lines at 1.5 bytes per pixel */
> >@@ -860,8 +868,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES]
> >= {
> > MALIDP550_DC_IRQ_SE,
> > .vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
> > },
> >-.pixel_formats = malidp550_de_formats,
> >-.n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
> >+.pixel_formats = malidp650_de_formats,
> >+.n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
> > .bus_align_bytes = 16,
> > },
> > .query_hw = malidp650_query_hw,
> >diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> >b/drivers/gpu/drm/arm/malidp_planes.c
> >index 49c37f6dd63e..33bbc29da774 100644
> >--- a/drivers/gpu/drm/arm/malidp_planes.c
> >+++ b/drivers/gpu/drm/arm/malidp_planes.c
> >@@ -196,13 +196,26 @@ static int malidp_de_plane_check(struct drm_plane
> >*plane,
> > ms->n_planes = fb->format->num_planes;
> > for (i = 0; i < ms->n_planes; i++) {
> > u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
> >-if (fb->pitches[i] & (alignment - 1)) {
> >+
> >+if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
> >i))
> >+& (alignment - 1)) {
> > DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
> > fb->pitches[i], i);
> > return -EINVAL;
> > }
> > }
> >
> >+if (fb->width % drm_format_info_block_width(fb->format, 0) ||
> >+fb->height % drm_format_info_block_height(fb->format, 0)) {
> >+DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
> >tile sizes");
> >+return -EINVAL;
> >+}
> >+if ((state->src_x >> 16) % drm_format_info_block_width(fb->format, 0) ||
> >+(state->src_y >> 16) % drm_format_info_block_height(fb->format, 0))
> >{
> >+DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
> >sizes");
> >+return -EINVAL;
> >+}
>
> Some local variables for block_w and block_h instead of all the
> function calls might be easier to parse in this function.
>
> >+
> > if ((state->crtc_w > mp->hwdev->max_line_size) ||
> > (state->crtc_h > mp->hwdev->max_line_size) ||
> > (state->crtc_w < mp->hwdev->min_line_size) ||
> >@@ -258,8 +271,14 @@ static void malidp_de_set_plane_pitches(struct
> >malidp_plane *mp,
> > num_strides = (mp->hwdev->hw->features &
> >MALIDP_DEVICE_LV_HAS_3_STRIDES) ? 3 : 2;
> >
> >+/*
> >+ * The drm convention for pitch is
Re: [PATCH v5 2/9] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
On Fri, Oct 19, 2018 at 02:09:38PM +0100, Brian Starkey wrote: > Hi Alex, > > On Fri, Oct 19, 2018 at 11:57:45AM +0100, Alexandru Gheorghe wrote: > >For some pixel formats .cpp structure in drm_format info it's not > >enough to describe the peculiarities of the pixel layout, for example > >tiled formats or packed formats at bit level. > > > >What's implemented here is to add three new members to drm_format_info > >that could describe such formats: > > > >- char_per_block[3] > >- block_w[3] > >- block_h[3] > > > >char_per_block will be put in a union alongside cpp, for transparent > >compatibility with the existing format descriptions. > > > >Regarding, block_w and block_h they are intended to be used through > >their equivalent getters drm_format_info_block_width / > >drm_format_info_block_height, the reason of the getters is to abstract > >the fact that for normal formats block_w and block_h will be unset/0, > >but the methods will be returning 1. > > > >Additionally, convenience function drm_format_info_min_pitch had been > >added that computes the minimum required pitch for a given pixel > >format and buffer width. > > > >Using that the following drm core functions had been updated to > >generically handle both block and non-block formats: > > > >- drm_fb_cma_get_gem_addr: for block formats it will just return the > > beginning of the block. > >- framebuffer_check: Use the newly added drm_format_info_min_pitch. > >- drm_gem_fb_create_with_funcs: Use the newly added > > drm_format_info_min_pitch. > >- In places where is not expecting to handle block formats, like fbdev > > helpers I just added some warnings in case the block width/height > > are greater than 1. > > > >Changes since v3: > >- Add helper function for computing the minimum required pitch. > >- Improve/cleanup documentation > > > >Signed-off-by: Alexandru Gheorghe > > I commented on a couple of tiny typographical things below, but > otherwise this looks good to me. Thanks! > > Reviewed-by: Brian Starkey > > >--- > >drivers/gpu/drm/drm_fb_cma_helper.c | 21 ++- > >drivers/gpu/drm/drm_fb_helper.c | 6 ++ > >drivers/gpu/drm/drm_fourcc.c | 62 > >drivers/gpu/drm/drm_framebuffer.c| 6 +- > >drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +- > >include/drm/drm_fourcc.h | 61 ++- > >6 files changed, 149 insertions(+), 9 deletions(-) > > > >diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > >b/drivers/gpu/drm/drm_fb_cma_helper.c > >index d52344a03aa8..83941a8ca0e0 100644 > >--- a/drivers/gpu/drm/drm_fb_cma_helper.c > >+++ b/drivers/gpu/drm/drm_fb_cma_helper.c > >@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct > >drm_framebuffer *fb, > >EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj); > > > >/** > >- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer > >+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for > >pixel > >+ * formats where values are grouped in blocks this will get you the > >beginning of > >+ * the block > > * @fb: The framebuffer > > * @state: Which state of drm plane > > * @plane: Which plane > >@@ -87,6 +89,14 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer > >*fb, > > struct drm_gem_cma_object *obj; > > dma_addr_t paddr; > > u8 h_div = 1, v_div = 1; > >+u32 block_w = drm_format_info_block_width(fb->format, plane); > >+u32 block_h = drm_format_info_block_height(fb->format, plane); > >+u32 block_size = fb->format->char_per_block[plane]; > >+u32 sample_x; > >+u32 sample_y; > >+u32 block_start_y; > >+u32 num_hblocks; > >+ > > nit: extra newline > > > > > obj = drm_fb_cma_get_gem_obj(fb, plane); > > if (!obj) > >@@ -99,8 +109,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct > >drm_framebuffer *fb, > > v_div = fb->format->vsub; > > } > > > >-paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div; > >-paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div; > >+sample_x = (state->src_x >> 16) / h_div; > >+sample_y = (state->src_y >> 16) / v_div; > >+block_start_y = (sample_y / block_h) * block_h; > >+num_hblocks = sample_x / block_w; > >+ > >+paddr += fb->pitches[plane] * block_start_y; > >+paddr += block_size * num_hblocks; > > > > return paddr; > >} > >diff --git a/drivers/gpu/drm/drm_fb_helper.c > >b/drivers/gpu/drm/drm_fb_helper.c > >index a504a5e05676..9add0d7da744 100644 > >--- a/drivers/gpu/drm/drm_fb_helper.c > >+++ b/drivers/gpu/drm/drm_fb_helper.c > >@@ -1595,6 +1595,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo > >*var, > > if (var->pixclock != 0 || in_dbg_master()) > > return -EINVAL; > > > >+if ((drm_format_info_block_width(fb->format, 0) > 1) || > >+(drm_format_info_block_height(fb->format, 0) > 1)) > >+return -EINVAL; > >+ > > /* > > * Changes struct fb_var_sc
Re: [PATCH v5 8/9] drm/selftest: Refactor test-drm_plane_helper
Hi Daniel,
On Fri, Oct 19, 2018 at 05:14:51PM +0200, Daniel Vetter wrote:
> On Fri, Oct 19, 2018 at 11:57:51AM +0100, Alexandru Gheorghe wrote:
> > The idea is to split test implementations in different compilation
> > units, but have one single place where we define the list of tests,
> > in this case(drm_modeset_selftests.h).
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > ...er_selftests.h => drm_modeset_selftests.h} | 0
> > .../drm/selftests/test-drm_modeset_common.c | 11 ++-
> > .../drm/selftests/test-drm_modeset_common.h | 2 +-
> > .../gpu/drm/selftests/test-drm_plane_helper.c | 19 +--
> > 4 files changed, 12 insertions(+), 20 deletions(-)
> > rename drivers/gpu/drm/selftests/{drm_plane_helper_selftests.h =>
> > drm_modeset_selftests.h} (100%)
> >
> > diff --git a/drivers/gpu/drm/selftests/drm_plane_helper_selftests.h
> > b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> > similarity index 100%
> > rename from drivers/gpu/drm/selftests/drm_plane_helper_selftests.h
> > rename to drivers/gpu/drm/selftests/drm_modeset_selftests.h
> > diff --git a/drivers/gpu/drm/selftests/test-drm_modeset_common.c
> > b/drivers/gpu/drm/selftests/test-drm_modeset_common.c
> > index fad5209043f1..2a7f93774006 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_modeset_common.c
> > +++ b/drivers/gpu/drm/selftests/test-drm_modeset_common.c
> > @@ -7,9 +7,18 @@
> >
> > #include "test-drm_modeset_common.h"
> >
> > +#define TESTS "drm_modeset_selftests.h"
> > +#include "drm_selftest.h"
> > +
> > +#include "drm_selftest.c"
> > +
> > static int __init test_drm_modeset_init(void)
> > {
> > - return test_drm_plane_helper();
> > + int err;
> > +
> > + err = run_selftests(selftests, ARRAY_SIZE(selftests), NULL);
> > +
> > + return err > 0 ? 0 : err;
> > }
> >
> > static void __exit test_drm_modeset_exit(void)
> > diff --git a/drivers/gpu/drm/selftests/test-drm_modeset_common.h
> > b/drivers/gpu/drm/selftests/test-drm_modeset_common.h
> > index bdeba264661f..b0065a2eb067 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_modeset_common.h
> > +++ b/drivers/gpu/drm/selftests/test-drm_modeset_common.h
> > @@ -13,6 +13,6 @@
> >
> > #define FAIL_ON(x) FAIL((x), "%s", "FAIL_ON(" __stringify(x) ")\n")
> >
> > -int test_drm_plane_helper(void);
> > +int igt_check_plane_state(void *ignored);
>
> I wonder whether we can't do some macro trickery to also generate these
> here from the selftest.h file. But that's probably for when we're drowning
> in these, which we're definitely not yet :-)
I agree.
>
> Reviewed-by: Daniel Vetter
Pushed the patch to drm-misc-next.
Thanks for the review.
>
> >
> > #endif
> > diff --git a/drivers/gpu/drm/selftests/test-drm_plane_helper.c
> > b/drivers/gpu/drm/selftests/test-drm_plane_helper.c
> > index 0dad2f812a27..0a9553f51796 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_plane_helper.c
> > +++ b/drivers/gpu/drm/selftests/test-drm_plane_helper.c
> > @@ -11,9 +11,6 @@
> >
> > #include "test-drm_modeset_common.h"
> >
> > -#define TESTS "drm_plane_helper_selftests.h"
> > -#include "drm_selftest.h"
> > -
> > static void set_src(struct drm_plane_state *plane_state,
> > unsigned src_x, unsigned src_y,
> > unsigned src_w, unsigned src_h)
> > @@ -76,7 +73,7 @@ static bool check_crtc_eq(struct drm_plane_state
> > *plane_state,
> > return true;
> > }
> >
> > -static int igt_check_plane_state(void *ignored)
> > +int igt_check_plane_state(void *ignored)
>
> > {
> > int ret;
> >
> > @@ -220,17 +217,3 @@ static int igt_check_plane_state(void *ignored)
> >
> > return 0;
> > }
> > -
> > -#include "drm_selftest.c"
> > -
> > -/**
> > - * test_drm_plane_helper - Run drm plane helper selftests.
> > - */
> > -int test_drm_plane_helper(void)
> > -{
> > - int err;
> > -
> > - err = run_selftests(selftests, ARRAY_SIZE(selftests), NULL);
> > -
> > - return err > 0 ? 0 : err;
> > -}
> > --
> > 2.18.0
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/9] drm: fourcc: Convert drm_format_info kerneldoc to in-line member documentation
Hi Maxime, Thanks for the review, pushed the patch to drm-misc-next. On Fri, Oct 19, 2018 at 02:54:18PM +0200, Maxime Ripard wrote: > On Fri, Oct 19, 2018 at 11:57:44AM +0100, Alexandru Gheorghe wrote: > > In-line member documentation seems to be desired way of documenting > > structure members. > > > > This change had been suggested by Daniel Vetter here: > > https://lists.freedesktop.org/archives/dri-devel/2018-October/192176.html > > > > Signed-off-by: Alexandru Gheorghe > > Reviewed-by: Maxime Ripard > > Thanks! > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/selftest: Add drm damage helper selftest
On Sat, Oct 20, 2018 at 01:27:48PM +, Deepak Singh Rawat wrote: > > > Hi Deepak, > > > > Something to consider, with this approach we kind of break the > > following behaviour: > > "Only tests enabled as module parameters are run, if no test is > > explicitly enabled then all of them are run" > > > > What I think we should do is have just one header where we put the > > selftest(check_plane_state, igt_check_plane_statea) > > ... > > selftest(damage_iter_no_damage, igt_damage_iter_no_damage) > > ... > > call it drm_modeset_selftests.h > > > > And separate just the implementations in different source files. > > > > Then we could call run_selftests just once from test_drm_modeset_init. > > > > Does this makes sense to you? > > > > Hi Alexandru, > > Thanks for the review. Yes this does make sense to me. I will change this > one to have run_selftests on one single header, single patch 01 is already > merged to drm-mics. I already sent that here, and I'll apply it shortly in drm-misc-next. [1] https://lists.freedesktop.org/archives/dri-devel/2018-October/193706.html > > > > > > > Cc: Daniel Vetter > > > > > Cc: alexandru-cosmin.gheor...@arm.com > > > > > Signed-off-by: Deepak Rawat > > > > > Reviewed-by: Daniel Vetter > > > > > Reviewed-by: Thomas Hellstrom > > > > > > > > I guess this needs your entire damage series to make sense, right? > > > > > > Ah yes sorry. Although this patch is same as what I sent earlier > > > except linking with test-drm_modeset.ko > > > > > > > > > > > Another question: Does anyone from vmwgfx want drm-misc commit rights > > for > > > > pushing stuff like this? > > > > > > Hi Daniel, Thanks for the suggestion. I am not sure about eligibility > > > criteria for > > > commit rights but I think I will wait until drm-mics is moved to gitlab > > > and I have > > > more experience working with open-source. Beside me Thomas works on > > > vmwgfx, I am not sure if he already have commit rights. > > > > > > > -Daniel > > > > > --- > > > > > drivers/gpu/drm/selftests/Makefile| 3 +- > > > > > .../selftests/drm_damage_helper_selftests.h | 22 + > > > > > .../drm/selftests/test-drm_damage_helper.c| 828 > > ++ > > > > > .../drm/selftests/test-drm_modeset_common.c | 10 +- > > > > > .../drm/selftests/test-drm_modeset_common.h | 1 + > > > > > 5 files changed, 862 insertions(+), 2 deletions(-) > > > > > create mode 100644 > > > > drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > > create mode 100644 drivers/gpu/drm/selftests/test- > > drm_damage_helper.c > > > > > > > > > > diff --git a/drivers/gpu/drm/selftests/Makefile > > > > b/drivers/gpu/drm/selftests/Makefile > > > > > index 7e6581921da0..c6e63ed12f02 100644 > > > > > --- a/drivers/gpu/drm/selftests/Makefile > > > > > +++ b/drivers/gpu/drm/selftests/Makefile > > > > > @@ -1,3 +1,4 @@ > > > > > -test-drm_modeset-y := test-drm_modeset_common.o test- > > > > drm_plane_helper.o > > > > > +test-drm_modeset-y := test-drm_modeset_common.o test- > > > > drm_plane_helper.o \ > > > > > + test-drm_damage_helper.o > > > > > > > > > > obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test- > > > > drm_modeset.o > > > > > diff --git a/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > > new file mode 100644 > > > > > index ..3a1cbe05bef0 > > > > > --- /dev/null > > > > > +++ b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > > @@ -0,0 +1,22 @@ > > > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > > > +selftest(damage_iter_no_damage, igt_damage_iter_no_damage) > > > > > +selftest(damage_iter_no_damage_fractional_src, > > > > igt_damage_iter_no_damage_fractional_src) > > > > > +selftest(damage_iter_no_damage_src_moved, > > > > igt_damage_iter_no_damage_src_moved) > > > > > +selftest(damage_iter_no_damage_fractional_src_moved, > > > > igt_damage_iter_no_damage_fractional_src_moved) > > > > > +selftest(damage_iter_no_damage_not_visible, > > > > igt_damage_iter_no_damage_not_visible) > > > > > +selftest(damage_iter_no_damage_no_crtc, > > > > igt_damage_iter_no_damage_no_crtc) > > > > > +selftest(damage_iter_no_damage_no_fb, > > > > igt_damage_iter_no_damage_no_fb) > > > > > +selftest(damage_iter_simple_damage, igt_damage_iter_simple_damage) > > > > > +selftest(damage_iter_single_damage, igt_damage_iter_single_damage) > > > > > +selftest(damage_iter_single_damage_intersect_src, > > > > igt_damage_iter_single_damage_intersect_src) > > > > > +selftest(damage_iter_single_damage_outside_src, > > > > igt_damage_iter_single_damage_outside_src) > > > > > +selftest(damage_iter_single_damage_fractional_src, > > > > igt_damage_iter_single_damage_fractional_src) > > > > > +selftest(damage_iter_single_damage_intersect_fractional_src, > > > > igt_damage_iter_single_damage_intersect_fractional_src) > > > > > +selftest(damage_iter_single_damage_outside_fractional_src,
Re: [PATCH v2 2/2] drm/selftest: Add drm damage helper selftest
Hi Deepak, Something to consider, with this approach we kind of break the following behaviour: "Only tests enabled as module parameters are run, if no test is explicitly enabled then all of them are run" What I think we should do is have just one header where we put the selftest(check_plane_state, igt_check_plane_statea) ... selftest(damage_iter_no_damage, igt_damage_iter_no_damage) ... call it drm_modeset_selftests.h And separate just the implementations in different source files. Then we could call run_selftests just once from test_drm_modeset_init. Does this makes sense to you? Thank you, Alex Gheorghe On Thu, Oct 18, 2018 at 01:32:03PM +, Deepak Singh Rawat wrote: > > On Tue, Oct 16, 2018 at 01:46:09PM -0700, Deepak Rawat wrote: > > > Selftest for drm damage helper iterator functions. > > > > > > Cc: Daniel Vetter > > > Cc: alexandru-cosmin.gheor...@arm.com > > > Signed-off-by: Deepak Rawat > > > Reviewed-by: Daniel Vetter > > > Reviewed-by: Thomas Hellstrom > > > > I guess this needs your entire damage series to make sense, right? > > Ah yes sorry. Although this patch is same as what I sent earlier > except linking with test-drm_modeset.ko > > > > > Another question: Does anyone from vmwgfx want drm-misc commit rights for > > pushing stuff like this? > > Hi Daniel, Thanks for the suggestion. I am not sure about eligibility > criteria for > commit rights but I think I will wait until drm-mics is moved to gitlab and I > have > more experience working with open-source. Beside me Thomas works on > vmwgfx, I am not sure if he already have commit rights. > > > -Daniel > > > --- > > > drivers/gpu/drm/selftests/Makefile| 3 +- > > > .../selftests/drm_damage_helper_selftests.h | 22 + > > > .../drm/selftests/test-drm_damage_helper.c| 828 ++ > > > .../drm/selftests/test-drm_modeset_common.c | 10 +- > > > .../drm/selftests/test-drm_modeset_common.h | 1 + > > > 5 files changed, 862 insertions(+), 2 deletions(-) > > > create mode 100644 > > drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > create mode 100644 drivers/gpu/drm/selftests/test-drm_damage_helper.c > > > > > > diff --git a/drivers/gpu/drm/selftests/Makefile > > b/drivers/gpu/drm/selftests/Makefile > > > index 7e6581921da0..c6e63ed12f02 100644 > > > --- a/drivers/gpu/drm/selftests/Makefile > > > +++ b/drivers/gpu/drm/selftests/Makefile > > > @@ -1,3 +1,4 @@ > > > -test-drm_modeset-y := test-drm_modeset_common.o test- > > drm_plane_helper.o > > > +test-drm_modeset-y := test-drm_modeset_common.o test- > > drm_plane_helper.o \ > > > + test-drm_damage_helper.o > > > > > > obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test- > > drm_modeset.o > > > diff --git a/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > new file mode 100644 > > > index ..3a1cbe05bef0 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > @@ -0,0 +1,22 @@ > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > +selftest(damage_iter_no_damage, igt_damage_iter_no_damage) > > > +selftest(damage_iter_no_damage_fractional_src, > > igt_damage_iter_no_damage_fractional_src) > > > +selftest(damage_iter_no_damage_src_moved, > > igt_damage_iter_no_damage_src_moved) > > > +selftest(damage_iter_no_damage_fractional_src_moved, > > igt_damage_iter_no_damage_fractional_src_moved) > > > +selftest(damage_iter_no_damage_not_visible, > > igt_damage_iter_no_damage_not_visible) > > > +selftest(damage_iter_no_damage_no_crtc, > > igt_damage_iter_no_damage_no_crtc) > > > +selftest(damage_iter_no_damage_no_fb, > > igt_damage_iter_no_damage_no_fb) > > > +selftest(damage_iter_simple_damage, igt_damage_iter_simple_damage) > > > +selftest(damage_iter_single_damage, igt_damage_iter_single_damage) > > > +selftest(damage_iter_single_damage_intersect_src, > > igt_damage_iter_single_damage_intersect_src) > > > +selftest(damage_iter_single_damage_outside_src, > > igt_damage_iter_single_damage_outside_src) > > > +selftest(damage_iter_single_damage_fractional_src, > > igt_damage_iter_single_damage_fractional_src) > > > +selftest(damage_iter_single_damage_intersect_fractional_src, > > igt_damage_iter_single_damage_intersect_fractional_src) > > > +selftest(damage_iter_single_damage_outside_fractional_src, > > igt_damage_iter_single_damage_outside_fractional_src) > > > +selftest(damage_iter_single_damage_src_moved, > > igt_damage_iter_single_damage_src_moved) > > > +selftest(damage_iter_single_damage_fractional_src_moved, > > igt_damage_iter_single_damage_fractional_src_moved) > > > +selftest(damage_iter_damage, igt_damage_iter_damage) > > > +selftest(damage_iter_damage_one_intersect, > > igt_damage_iter_damage_one_intersect) > > > +selftest(damage_iter_damage_one_outside, > > igt_damage_iter_damage_one_outside) > > > +selftest(damage_iter_damage_src_moved, > > igt_damage_iter_damage_src_moved) > > > +self
Re: [PATCH v3 04/18] drm/selftest: Add drm damage helper selftest
On Tue, Oct 16, 2018 at 02:21:17PM +0200, Daniel Vetter wrote: > On Mon, Oct 15, 2018 at 04:11:41PM +, Deepak Singh Rawat wrote: > > > On Wed, Oct 10, 2018 at 05:16:43PM -0700, Deepak Rawat wrote: > > > > Selftest for drm damage helper iterator functions. > > > > > > > > Cc: ville.syrj...@linux.intel.com > > > > Cc: Daniel Vetter > > > > Cc: Pekka Paalanen > > > > Cc: Daniel Stone > > > > Cc: intel-...@lists.freedesktop.org > > > > Cc: igt-...@lists.freedesktop.org > > > > Cc: petri.latv...@intel.com > > > > Cc: ch...@chris-wilson.co.uk > > > > Signed-off-by: Deepak Rawat > > > > --- > > > > drivers/gpu/drm/selftests/Makefile| 3 +- > > > > .../selftests/drm_damage_helper_selftests.h | 22 + > > > > .../drm/selftests/test-drm_damage_helper.c| 844 > > > ++ > > > > 3 files changed, 868 insertions(+), 1 deletion(-) > > > > create mode 100644 > > > drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > create mode 100644 drivers/gpu/drm/selftests/test- > > > drm_damage_helper.c > > > > > > > > diff --git a/drivers/gpu/drm/selftests/Makefile > > > b/drivers/gpu/drm/selftests/Makefile > > > > index 9fc349fa18e9..88ac216f5962 100644 > > > > --- a/drivers/gpu/drm/selftests/Makefile > > > > +++ b/drivers/gpu/drm/selftests/Makefile > > > > @@ -1 +1,2 @@ > > > > -obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm- > > > helper.o > > > > +obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm- > > > helper.o \ > > > > + test-drm_damage_helper.o > > > > > > With the testcase intagrated into the test-drm-helper.ko module, for > > > patches 1-4 in this series: > > > > > > Reviewed-by: Daniel Vetter > > > > > > Obviously needs some adjusting on the igt side too, since we seem to be > > > missing the igt scaffolding for tests-drm-helper.ko. > > > -Daniel > > > > Hi Daniel, > > > > Thanks for the review. I am a little confused here. Should we have single > > kernel module for drm plane helper selftest and damage helper selftest? > > Also shall I rename the kernel selfttest to kms_*? > > > > For user-space igt test it should be it makes sense to rename to > > kms_selftets? > > Since I went back&forth on this way too many times: > - igt should be called kms_selftest. Please work together with igt > maintainers (Arek and Petri), since we also need to update the CI > building infrastructure to make sure it updates the list of subtests > implemented by the kernel. > > - Kernel module I'd call test-drm_modeset.ko. That kernel module can then > include the existing test-drm-helper.c (could probably rename to > test-drm_plane_helper.c for clarity) and your new damage helper (named > test-drm_damage_helper.c for consistency). > > Does that make sense to everyone? I was trying to add some selftests, as well here [1], with that in mind, I think it makes sense to have just one module, call it "test-drm_modeset" or whatever and separate the tests source code base on whatever core functionality they are testing. Besides compiling everything together, probably some stuff will have to move out of test-drm-helper.c into some common header. For example this "FAIL/FAIL_ON" macros [1] https://lists.freedesktop.org/archives/dri-devel/2018-October/192973.html > > Thanks, Daniel > > > > > > > > > > diff --git a/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > new file mode 100644 > > > > index ..3a1cbe05bef0 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h > > > > @@ -0,0 +1,22 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > > +selftest(damage_iter_no_damage, igt_damage_iter_no_damage) > > > > +selftest(damage_iter_no_damage_fractional_src, > > > igt_damage_iter_no_damage_fractional_src) > > > > +selftest(damage_iter_no_damage_src_moved, > > > igt_damage_iter_no_damage_src_moved) > > > > +selftest(damage_iter_no_damage_fractional_src_moved, > > > igt_damage_iter_no_damage_fractional_src_moved) > > > > +selftest(damage_iter_no_damage_not_visible, > > > igt_damage_iter_no_damage_not_visible) > > > > +selftest(damage_iter_no_damage_no_crtc, > > > igt_damage_iter_no_damage_no_crtc) > > > > +selftest(damage_iter_no_damage_no_fb, > > > igt_damage_iter_no_damage_no_fb) > > > > +selftest(damage_iter_simple_damage, > > > igt_damage_iter_simple_damage) > > > > +selftest(damage_iter_single_damage, igt_damage_iter_single_damage) > > > > +selftest(damage_iter_single_damage_intersect_src, > > > igt_damage_iter_single_damage_intersect_src) > > > > +selftest(damage_iter_single_damage_outside_src, > > > igt_damage_iter_single_damage_outside_src) > > > > +selftest(damage_iter_single_damage_fractional_src, > > > igt_damage_iter_single_damage_fractional_src) > > > > +selftest(damage_iter_single_damage_intersect_fractional_src, > > > igt_damage_iter_single_damage_intersect_fractional_src) > >
Re: [PATCH v3 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
Hi Swati,
On Mon, Oct 15, 2018 at 01:39:54PM +0530,
swatisha...@outlook.ms-acdc.office.com wrote:
Btw, I can't reply to this address.
> From: Vidya Srinivas
>
>
> The following pixel formats are packed format that follows 4:2:2
> chroma sampling. For memory represenation each component is
> allocated 16 bits each. Thus each pixel occupies 32bit.
>
> Y210: Valid data occupies MSB 10 bits.
> LSB 6 bits are filled with zeroes.
> Y212: Valid data occupies MSB 12 bits.
> LSB 4 bits are filled with zeroes.
> Y216: Valid data occupies 16 bits,
> doesn't require any padding bits.
>
> First 16 bits stores the Y value and the next 16 bits stores one
> of the chroma samples alternatively. The first luma sample will
> be accompanied by first U sample and second luma sample is
> accompanied by the first V sample.
>
> v2: is_yuv setted to true (mahesh)
> different order of yuv samples (mahesh): still update from
> hardware team pending
> change in comment (alexandru)
>
> v3: change in patch comment (juha)
> change in fourcc_code comment (juha)
> different order of yuv samples needs to be defined for Y210/
> Y212/Y216 (update from h/w folks): not including in this patch,
> will do in other patch series (if reqd)
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 90a1c84..667527b 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -225,6 +225,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y212,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y216,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
I think this should be .cpp {4, 0, 0}, otherwise framebuffer_check
will demand a min pitch(width * cpp) that's greater of what's actually really
required.
I think you should apply the same convetion as for other 422 packed
formats see DRM_FORMAT_UYVY and others.
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 139632b..af1c900 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -153,6 +153,14 @@
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>
> /*
> + * packed Y2xx indicate for each component, xx valid data occupy msb
> + * 16-xx padding occupy lsb
> + */
> +#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
> Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
> +#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
> Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian */
> +#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
> Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
> +
> +/*
> * 2 plane RGB + A
> * index 0 = RGB plane, same format as the corresponding non _A8 format has
> * index 1 = A plane, [7:0] A
> --
> 1.9.1
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
Hi Swati,
On Mon, Oct 15, 2018 at 01:39:54PM +0530,
swatisha...@outlook.ms-acdc.office.com wrote:
> From: Vidya Srinivas
>
> The following pixel formats are packed format that follows 4:2:2
> chroma sampling. For memory represenation each component is
> allocated 16 bits each. Thus each pixel occupies 32bit.
>
> Y210: Valid data occupies MSB 10 bits.
> LSB 6 bits are filled with zeroes.
> Y212: Valid data occupies MSB 12 bits.
> LSB 4 bits are filled with zeroes.
> Y216: Valid data occupies 16 bits,
> doesn't require any padding bits.
>
> First 16 bits stores the Y value and the next 16 bits stores one
> of the chroma samples alternatively. The first luma sample will
> be accompanied by first U sample and second luma sample is
> accompanied by the first V sample.
>
> v2: is_yuv setted to true (mahesh)
> different order of yuv samples (mahesh): still update from
> hardware team pending
> change in comment (alexandru)
>
> v3: change in patch comment (juha)
> change in fourcc_code comment (juha)
> different order of yuv samples needs to be defined for Y210/
> Y212/Y216 (update from h/w folks): not including in this patch,
> will do in other patch series (if reqd)
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 90a1c84..667527b 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -225,6 +225,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y212,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y216,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
Shouldn't this be .cpp {4, 0, 0}? otherwise framebuffer_check will
require a minimum pitch bigger than actually required.
I think you need to apply the same convention as with other 422 packed
formats, see DRM_FORMAT_YUYV & DRM_FORMAT_UYVY.
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 139632b..af1c900 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -153,6 +153,14 @@
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>
> /*
> + * packed Y2xx indicate for each component, xx valid data occupy msb
> + * 16-xx padding occupy lsb
> + */
> +#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
> Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
> +#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
> Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian */
> +#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
> Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
> +
> +/*
> * 2 plane RGB + A
> * index 0 = RGB plane, same format as the corresponding non _A8 format has
> * index 1 = A plane, [7:0] A
> --
> 1.9.1
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
On Thu, Oct 11, 2018 at 10:29:42AM +0200, Daniel Vetter wrote: > On Mon, Oct 08, 2018 at 09:52:04AM +0000, Alexandru-Cosmin Gheorghe wrote: > > Hi Daniel, > > > > Thanks for having a look. > > > > On Fri, Oct 05, 2018 at 04:51:48PM +0200, Daniel Vetter wrote: > > > On Fri, Oct 05, 2018 at 09:26:47AM +, Alexandru-Cosmin Gheorghe wrote: > > > > For some pixel formats .cpp structure in drm_format info it's not > > > > enough to describe the peculiarities of the pixel layout, for example > > > > tiled formats or packed formats at bit level. > > > > > > > > What's implemented here is to add three new members to drm_format_info > > > > that could describe such formats: > > > > > > > > - char_per_block[3] > > > > - block_w[3] > > > > - block_h[3] > > > > > > > > char_per_block will be put in a union alongside cpp, for transparent > > > > compatibility with the existing format descriptions. > > > > > > > > Regarding, block_w and block_h they are intended to be used through > > > > their equivalent getters drm_format_info_block_width / > > > > drm_format_info_block_height, the reason of the getters is to abstract > > > > the fact that for normal formats block_w and block_h will be unset/0, > > > > but the methods will be returning 1. > > > > > > > > Using that the following drm core functions had been updated to > > > > generically handle both block and non-block formats: > > > > > > > > - drm_fb_cma_get_gem_addr: for block formats it will just return the > > > > beginning of the block. > > > > - framebuffer_check: Updated to compute the minimum pitch as > > > > DIV_ROUND_UP(width * char_per_block, > > > > drm_format_info_block_width(info, i) > > > > * drm_format_info_block_height(info, i)) > > > > - drm_gem_fb_create_with_funcs: Updated to compute the size of the > > > > last line of pixels with the same formula as for the minimum pitch. > > > > - In places where is not expecting to handle block formats, like fbdev > > > > helpers I just added some warnings in case the block width/height > > > > are greater than 1. > > > > > > > > Signed-off-by: Alexandru Gheorghe > > > > Reviewed-by: Liviu Dudau > > > > --- > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 21 -- > > > > drivers/gpu/drm/drm_fb_helper.c | 6 +++ > > > > drivers/gpu/drm/drm_fourcc.c | 40 > > > > drivers/gpu/drm/drm_framebuffer.c| 9 +++-- > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- > > > > include/drm/drm_fourcc.h | 29 +- > > > > 6 files changed, 101 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > > > > b/drivers/gpu/drm/drm_fb_cma_helper.c > > > > index 47e0e2f6642d..f8293f4d96cf 100644 > > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > > > > @@ -72,7 +72,9 @@ struct drm_gem_cma_object > > > > *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb, > > > > EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj); > > > > > > > > /** > > > > - * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer > > > > + * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, > > > > for pixel > > > > + * formats where values are grouped in blocks this will get you the > > > > beginning of > > > > + * the block > > > > * @fb: The framebuffer > > > > * @state: Which state of drm plane > > > > * @plane: Which plane > > > > @@ -87,6 +89,14 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct > > > > drm_framebuffer *fb, > > > > struct drm_gem_cma_object *obj; > > > > dma_addr_t paddr; > > > > u8 h_div = 1, v_div = 1; > > > > + u32 block_w = drm_format_info_block_width(fb->format, plane); > > > > + u32 block_h = drm_format_info_block_height(fb->format, plane); > > > > + u32 block_size = fb->format->char_per_block[plane]; > > > > + u32 sample_x; > > > > + u32 sample_y; > > > >
Re: [PATCH v3 0/6] Add method to describe tile/bit_level_packed formats
On Fri, Oct 05, 2018 at 04:58:38PM +0200, Daniel Vetter wrote: > On Fri, Oct 05, 2018 at 09:26:43AM +0000, Alexandru-Cosmin Gheorghe wrote: > > There has been some discussion about extending drm core to handle > > linear tile formats, in the series sent by me here [1] and how to > > handle formats that are intended to be used just with > > modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC > > here [3] and [4]. > > > > Hence, this big-merged series: > > > > Patches 1-3: handle tiled formats both in core and in malidp driver, > > this is done by extending drm_format_info with three new fields > > char_per_block, block_w, block_h and consistently handle in the generic > > code paths, both linear tiled formats and normal formats. > > What's different from [1] is the interpretation of pitch for tile > > formats which has been kept to be the same as for the other formats: > > pitch = average_chars_per_pixel * width. > > > > Patches 4-6: Introduce the YUV AFBC formats, the only thing noteworthy > > here is that cpp/char_per_block are set to 0 for formats where it's > > mandatory to be used together with a non-linear modifier and then that > > is used to bypass pitch check in framebuffer_check for formats that > > have cpp/char_per_block set to 0. > > > > [1] > > https://lists.freedesktop.org/archives/dri-devel/2018-September/188245.html > > [2] > > https://lists.freedesktop.org/archives/dri-devel/2018-September/189620.html > > [3] > > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true > > [4] > > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-14&show_html=true > > > > Alexandru Gheorghe (4): > > drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info > > drm/fourcc: Add fourcc for Mali linear tiled formats > > drm: mali-dp: Enable Mali-DP tiled buffer formats > > drm: Extend framebuffer_check to handle formats with > > cpp/char_per_block 0 > > > > Brian Starkey (2): > > drm/fourcc: Add AFBC yuv fourccs for Mali > > drm/afbc: Add AFBC modifier usage documentation > > I think at the design level we're getting there, yay! Bunch of > comments/suggestions/ideas on patch one. > > It looks like the patch 7 is missing though, since the fancy formats where > you have no linear layout isn't enabled in mali-dp (afaics at least). > Depending what those look like, my suggestion to require drivers to use > ->get_format_info instead might or might not work. Yes, patch 7 is missing, Ayan is working on that, I'm not sure if on next version we should send one big series, with that as well, or split it in two, by keeping the first three patches in a separate series, any preferences ? Anyway, regarding using get_format_info to trick check_framebuffer to validate the pitch, the driver could invent some numbers to populate a drm_format_info, but it doesn't make too much sense because we are more restrictive than that so the driver will need to do some sort of validation anyway. > > Cheers, Daniel > > > > > Documentation/gpu/afbc.rst | 233 +++ > > Documentation/gpu/drivers.rst| 1 + > > MAINTAINERS | 1 + > > drivers/gpu/drm/arm/malidp_hw.c | 14 +- > > drivers/gpu/drm/arm/malidp_planes.c | 23 +- > > drivers/gpu/drm/drm_fb_cma_helper.c | 21 +- > > drivers/gpu/drm/drm_fb_helper.c | 6 + > > drivers/gpu/drm/drm_fourcc.c | 65 ++ > > drivers/gpu/drm/drm_framebuffer.c| 13 +- > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- > > include/drm/drm_fourcc.h | 29 ++- > > include/uapi/drm/drm_fourcc.h| 31 +++ > > 12 files changed, 428 insertions(+), 13 deletions(-) > > create mode 100644 Documentation/gpu/afbc.rst > > > > -- > > 2.18.0 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
Hi Daniel, Thanks for having a look. On Fri, Oct 05, 2018 at 04:51:48PM +0200, Daniel Vetter wrote: > On Fri, Oct 05, 2018 at 09:26:47AM +0000, Alexandru-Cosmin Gheorghe wrote: > > For some pixel formats .cpp structure in drm_format info it's not > > enough to describe the peculiarities of the pixel layout, for example > > tiled formats or packed formats at bit level. > > > > What's implemented here is to add three new members to drm_format_info > > that could describe such formats: > > > > - char_per_block[3] > > - block_w[3] > > - block_h[3] > > > > char_per_block will be put in a union alongside cpp, for transparent > > compatibility with the existing format descriptions. > > > > Regarding, block_w and block_h they are intended to be used through > > their equivalent getters drm_format_info_block_width / > > drm_format_info_block_height, the reason of the getters is to abstract > > the fact that for normal formats block_w and block_h will be unset/0, > > but the methods will be returning 1. > > > > Using that the following drm core functions had been updated to > > generically handle both block and non-block formats: > > > > - drm_fb_cma_get_gem_addr: for block formats it will just return the > > beginning of the block. > > - framebuffer_check: Updated to compute the minimum pitch as > > DIV_ROUND_UP(width * char_per_block, drm_format_info_block_width(info, > > i) > > * drm_format_info_block_height(info, i)) > > - drm_gem_fb_create_with_funcs: Updated to compute the size of the > > last line of pixels with the same formula as for the minimum pitch. > > - In places where is not expecting to handle block formats, like fbdev > > helpers I just added some warnings in case the block width/height > > are greater than 1. > > > > Signed-off-by: Alexandru Gheorghe > > Reviewed-by: Liviu Dudau > > --- > > drivers/gpu/drm/drm_fb_cma_helper.c | 21 -- > > drivers/gpu/drm/drm_fb_helper.c | 6 +++ > > drivers/gpu/drm/drm_fourcc.c | 40 > > drivers/gpu/drm/drm_framebuffer.c| 9 +++-- > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- > > include/drm/drm_fourcc.h | 29 +- > > 6 files changed, 101 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > > b/drivers/gpu/drm/drm_fb_cma_helper.c > > index 47e0e2f6642d..f8293f4d96cf 100644 > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > > @@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct > > drm_framebuffer *fb, > > EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj); > > > > /** > > - * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer > > + * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for > > pixel > > + * formats where values are grouped in blocks this will get you the > > beginning of > > + * the block > > * @fb: The framebuffer > > * @state: Which state of drm plane > > * @plane: Which plane > > @@ -87,6 +89,14 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct > > drm_framebuffer *fb, > > struct drm_gem_cma_object *obj; > > dma_addr_t paddr; > > u8 h_div = 1, v_div = 1; > > + u32 block_w = drm_format_info_block_width(fb->format, plane); > > + u32 block_h = drm_format_info_block_height(fb->format, plane); > > + u32 block_size = fb->format->char_per_block[plane]; > > + u32 sample_x; > > + u32 sample_y; > > + u32 block_start_y; > > + u32 num_hblocks; > > + > > > > obj = drm_fb_cma_get_gem_obj(fb, plane); > > if (!obj) > > @@ -99,8 +109,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct > > drm_framebuffer *fb, > > v_div = fb->format->vsub; > > } > > > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div; > > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div; > > + sample_x = (state->src_x >> 16) / h_div; > > + sample_y = (state->src_y >> 16) / v_div; > > + block_start_y = (sample_y / block_h) * block_h; > > + num_hblocks = sample_x / block_w; > > + > > + paddr += fb->pitches[plane] * block_start_y; > > + paddr += block_size * num_hblocks; > > > > return paddr; > > } > > diff --git a/drivers/gpu/drm/drm_fb_helper.c >
[PATCH v3 3/6] drm: mali-dp: Enable Mali-DP tiled buffer formats
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 23 +--
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index c94a4422e0e9..e01fc0e5b503 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -77,12 +77,18 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
- { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
+ { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
};
+static const struct malidp_format_id malidp650_de_formats[] = {
+ MALIDP_COMMON_FORMATS,
+ { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
+};
+
static const struct malidp_layer malidp500_layers[] = {
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0 },
@@ -595,6 +601,8 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_BGR565:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_X0L0:
+ case DRM_FORMAT_X0L2:
bytes_per_col = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
@@ -860,8 +868,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
- .pixel_formats = malidp550_de_formats,
- .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
+ .pixel_formats = malidp650_de_formats,
+ .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 49c37f6dd63e..33bbc29da774 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -196,13 +196,26 @@ static int malidp_de_plane_check(struct drm_plane *plane,
ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if (fb->pitches[i] & (alignment - 1)) {
+
+ if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
}
}
+ if (fb->width % drm_format_info_block_width(fb->format, 0) ||
+ fb->height % drm_format_info_block_height(fb->format, 0)) {
+ DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
+ return -EINVAL;
+ }
+ if ((state->src_x >> 16) % drm_format_info_block_width(fb->format, 0) ||
+ (state->src_y >> 16) % drm_format_info_block_height(fb->format, 0))
{
+ DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
+ return -EINVAL;
+ }
+
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
@@ -258,8 +271,14 @@ static void malidp_de_set_plane_pitches(struct
malidp_plane *mp,
num_strides = (mp->hwdev->hw->features &
MALIDP_DEVICE_LV_HAS_3_STRIDES) ? 3 : 2;
+ /*
+* The drm convention for pitch is that it needs to cover width * cpp,
+* but our hardware wants the pitch/stride to cover all rows included
+* in a tile.
+*/
for (i = 0; i < num_strides; ++i)
- malidp_hw_write(mp->hwdev, pitches[i],
+ malidp_hw_write(mp->hwdev, pitches[i] *
+
drm_format_info_block_height(mp->base.state->fb->format, i),
mp->layer->base +
mp->layer->stride_offset + i * 4);
}
--
[PATCH v3 4/6] drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This had been discussed here.
[1]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/drm_framebuffer.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 4e14013788cd..66ec126b7faf 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -200,6 +200,10 @@ static int framebuffer_check(struct drm_device *dev,
drm_format_info_block_width(info, i) *
drm_format_info_block_height(info, i));
+ if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
+ DRM_DEBUG_KMS("Format requires non-linear modifier for
plane %d\n", i);
+ return -EINVAL;
+ }
if (!r->handles[i]) {
DRM_DEBUG_KMS("no buffer object handle for plane %d\n",
i);
return -EINVAL;
@@ -211,7 +215,7 @@ static int framebuffer_check(struct drm_device *dev,
if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
UINT_MAX)
return -ERANGE;
- if (r->pitches[i] < min_pitch) {
+ if (block_size && r->pitches[i] < min_pitch) {
DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
return -EINVAL;
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/6] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V)
[PATCH v3 6/6] drm/afbc: Add AFBC modifier usage documentation
From: Brian Starkey AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- Documentation/gpu/afbc.rst| 233 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 238 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index ..922d955da192 --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,233 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) +
[PATCH v3 1/6] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Updated to compute the minimum pitch as
DIV_ROUND_UP(width * char_per_block, drm_format_info_block_width(info,
i)
* drm_format_info_block_height(info, i))
- drm_gem_fb_create_with_funcs: Updated to compute the size of the
last line of pixels with the same formula as for the minimum pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/drm_fb_cma_helper.c | 21 --
drivers/gpu/drm/drm_fb_helper.c | 6 +++
drivers/gpu/drm/drm_fourcc.c | 40
drivers/gpu/drm/drm_framebuffer.c| 9 +++--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +-
include/drm/drm_fourcc.h | 29 +-
6 files changed, 101 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 47e0e2f6642d..f8293f4d96cf 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,14 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
+
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +109,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a504a5e05676..9add0d7da744 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1595,6 +1595,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1969,6 +1973,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+ WARN_ON((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1));
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
info->var.yres_virtual = fb->height;
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index a154
[PATCH v3 2/6] drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0c9725ffd5e9..13b2163e5d0b 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -228,6 +228,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0},
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0},
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0},
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0},
+ .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 600106adf91f..4de86dbf40ca 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -152,6 +152,20 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/*
+ * packed YCbCr420 2x2 tiled formats
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
+ */
+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
+
+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
+/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_X0L2fourcc_code('X', '0', 'L', '2')
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/6] Add method to describe tile/bit_level_packed formats
There has been some discussion about extending drm core to handle linear tile formats, in the series sent by me here [1] and how to handle formats that are intended to be used just with modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC here [3] and [4]. Hence, this big-merged series: Patches 1-3: handle tiled formats both in core and in malidp driver, this is done by extending drm_format_info with three new fields char_per_block, block_w, block_h and consistently handle in the generic code paths, both linear tiled formats and normal formats. What's different from [1] is the interpretation of pitch for tile formats which has been kept to be the same as for the other formats: pitch = average_chars_per_pixel * width. Patches 4-6: Introduce the YUV AFBC formats, the only thing noteworthy here is that cpp/char_per_block are set to 0 for formats where it's mandatory to be used together with a non-linear modifier and then that is used to bypass pitch check in framebuffer_check for formats that have cpp/char_per_block set to 0. [1] https://lists.freedesktop.org/archives/dri-devel/2018-September/188245.html [2] https://lists.freedesktop.org/archives/dri-devel/2018-September/189620.html [3] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true [4] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-14&show_html=true Alexandru Gheorghe (4): drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info drm/fourcc: Add fourcc for Mali linear tiled formats drm: mali-dp: Enable Mali-DP tiled buffer formats drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0 Brian Starkey (2): drm/fourcc: Add AFBC yuv fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst | 233 +++ Documentation/gpu/drivers.rst| 1 + MAINTAINERS | 1 + drivers/gpu/drm/arm/malidp_hw.c | 14 +- drivers/gpu/drm/arm/malidp_planes.c | 23 +- drivers/gpu/drm/drm_fb_cma_helper.c | 21 +- drivers/gpu/drm/drm_fb_helper.c | 6 + drivers/gpu/drm/drm_fourcc.c | 65 ++ drivers/gpu/drm/drm_framebuffer.c| 13 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- include/drm/drm_fourcc.h | 29 ++- include/uapi/drm/drm_fourcc.h| 31 +++ 12 files changed, 428 insertions(+), 13 deletions(-) create mode 100644 Documentation/gpu/afbc.rst -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm: Introduce new DRM_FORMAT_XYUV
On Thu, Oct 04, 2018 at 12:04:57PM +, Lisovskiy, Stanislav wrote:
> On Wed, 2018-10-03 at 08:07 +0000, Alexandru-Cosmin Gheorghe wrote:
> > On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> > > On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > > > Hi,
> > > >
> > > > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy
> > > > wrote:
> > > > > v5: This is YUV444 packed format same as AYUV, but without
> > > > > alpha,
> > > > > as supported by i915.
> > > > >
> > > > > v6: Removed unneeded initializer for new XYUV format.
> > > > >
> > > > > v7: Added is_yuv field initialization according to latest
> > > > > drm_fourcc format structure initialization changes.
> > > > >
> > > > > v8: Edited commit message to be more clear about skl+, renamed
> > > > > PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this
> > > > > format
> > > > > doesn't support per-pixel alpha. Fixed minor code issues.
> > > > >
> > > > > v9: Moved DRM format check to proper place in
> > > > > intel_framebuffer_init.
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy > > > > om>
> > > >
> > > > Reviewed-by: Alexandru Gheorghe > > > m>
> > > >
> > > > I'm planning of sending a new version with my series[1], do you
> > > > think
> > > > this patch will get merged soon, or is there anything else that
> > > > needs
> > > > to be done.
> > > >
> > > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-
> > > > August/186963.html
> > >
> > > Hi,
> > >
> > > I had to implement IGT test case and xf86-video-intel support for
> > > this
> > > new format(in order to check that it works with gstreamer as we
> > > have
> > > userspace requirement for this change), so currently I guess all
> > > the
> > > requirements are met. I might need to do some
> > > minor changes in those patches though, once I get some feedback.
> >
> > A bit offtopic do we need userspace for adding a new fourcc as well,
> > I thought those are extempted from "must have userspace rule".
>
> Well, at least in my case I was asked to do that.
> Interesting task though :)
> Currently I check with GStreamer, so that video works both in textured
> and sprite format.
> BTW, I have changed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV so that it
> is compliant with your change. As I understood we've agreed to have it
> called that way instead of DRM_FORMAT_XYUV. Are you ok with that?
>
Yes DRM_FORMAT_XYUV, it's fine by me.
Thanks.
> I will then send a new patch for IGT, xf86-video-intel and drm today.
>
> > >
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_fourcc.c | 1 +
> > > > > include/uapi/drm/drm_fourcc.h | 1 +
> > > > > 2 files changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > index be1d6aaef651..60752d0be9d8 100644
> > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > > @@ -190,6 +190,7 @@ const struct drm_format_info
> > > > > *__drm_format_info(u32 format)
> > > > > { .format = DRM_FORMAT_UYVY,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub =
> > > > > 1,
> > > > > .is_yuv = true },
> > > > > { .format = DRM_FORMAT_VYUY,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub =
> > > > > 1,
> > > > > .is_yuv = true },
> > > > > { .format = DRM_FORMAT_AYUV,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub =
> > > > > 1,
> > > > > .has_alpha = true, .is_yuv = true },
> > > > > + { .format = DRM_FORMAT_XYUV,.d
> > > > > epth
> > > > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub
Re: [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
On Wed, Oct 03, 2018 at 02:31:08PM +0300, Juha-Pekka Heikkila wrote:
> Hi Alex,
>
> For my patches there seems limited interest to get them merged before IGT
> support these modes..I'm not holding my breath for this.
I'm interested if that counts.
I asked the same question on the DRM_FORMAT_XYUV thread, do we need to
wait for userspace to get new fourcc merged.
>
> https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html
>
> /Juha-Pekka
>
> On 02.10.2018 18:00, Alexandru-Cosmin Gheorghe wrote:
> >Hi,
> >
> >How is this going on, anything holding it back from getting merged ?
> >I'm interested in adding/using P010, [1]
> >
> >Thank you,
> >Alex Gheorghe
> >
> >[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
> >
> >On Thu, Aug 30, 2018 at 03:41:11PM +0300, Juha-Pekka Heikkila wrote:
> >>Add P010 definition, semi-planar yuv format where each component
> >>is 16 bits 10 msb containing color value. First come Y plane [10:6]
> >>followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
> >>
> >>Add P012 definition, semi-planar yuv format where each component
> >>is 16 bits 12 msb containing color value. First come Y plane [12:4]
> >>followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
> >>
> >>Add P016 definition, semi-planar yuv format where each component
> >>is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
> >>plane [16:16]
> >>
> >>Signed-off-by: Juha-Pekka Heikkila
> >>---
> >> drivers/gpu/drm/drm_fourcc.c | 3 +++
> >> include/uapi/drm/drm_fourcc.h | 10 ++
> >> 2 files changed, 13 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >>index 35c1e27..32e07a2 100644
> >>--- a/drivers/gpu/drm/drm_fourcc.c
> >>+++ b/drivers/gpu/drm/drm_fourcc.c
> >>@@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32
> >>format)
> >>{ .format = DRM_FORMAT_UYVY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true
> >> },
> >>{ .format = DRM_FORMAT_VYUY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true
> >> },
> >>{ .format = DRM_FORMAT_AYUV,.depth = 0,
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha =
> >> true, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_P010,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >>+ { .format = DRM_FORMAT_P012,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >>+ { .format = DRM_FORMAT_P016,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >>};
> >>unsigned int i;
> >>diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >>index 2ed46e9..daaabb1 100644
> >>--- a/include/uapi/drm/drm_fourcc.h
> >>+++ b/include/uapi/drm/drm_fourcc.h
> >>@@ -178,6 +178,16 @@ extern "C" {
> >> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> >> non-subsampled Cb:Cr plane */
> >> /*
> >>+ * 2 plane YCbCr
> >>+ * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
> >>+ * component xxx msb Y [xxx:16-xxx]
> >>+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian
> >>[xxx:16-xxx:xxx:16-xxx]
> >>+ */
> >>+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
> >>subsampled Cr:Cb plane, 10 bit per channel */
> >>+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
> >>subsampled Cr:Cb plane, 12 bit per channel */
> >>+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
> >>subsampled Cr:Cb plane, 16 bit per channel */
> >>+
> >>+/*
> >> * 3 plane YCbCr
> >> * index 0: Y plane, [7:0] Y
> >> * index 1: Cb plane, [7:0] Cb
> >>--
> >>2.7.4
> >>
> >>___
> >>dri-devel mailing list
> >>dri-devel@lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm: Introduce new DRM_FORMAT_XYUV
On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2018-10-02 at 15:28 +0000, Alexandru-Cosmin Gheorghe wrote:
> > Hi,
> >
> > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy wrote:
> > > v5: This is YUV444 packed format same as AYUV, but without alpha,
> > > as supported by i915.
> > >
> > > v6: Removed unneeded initializer for new XYUV format.
> > >
> > > v7: Added is_yuv field initialization according to latest
> > > drm_fourcc format structure initialization changes.
> > >
> > > v8: Edited commit message to be more clear about skl+, renamed
> > > PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
> > > doesn't support per-pixel alpha. Fixed minor code issues.
> > >
> > > v9: Moved DRM format check to proper place in
> > > intel_framebuffer_init.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> >
> > Reviewed-by: Alexandru Gheorghe
> >
> > I'm planning of sending a new version with my series[1], do you think
> > this patch will get merged soon, or is there anything else that needs
> > to be done.
> >
> > [1] https://lists.freedesktop.org/archives/dri-devel/2018-
> > August/186963.html
>
> Hi,
>
> I had to implement IGT test case and xf86-video-intel support for this
> new format(in order to check that it works with gstreamer as we have
> userspace requirement for this change), so currently I guess all the
> requirements are met. I might need to do some
> minor changes in those patches though, once I get some feedback.
A bit offtopic do we need userspace for adding a new fourcc as well,
I thought those are extempted from "must have userspace rule".
>
> >
> > > ---
> > > drivers/gpu/drm/drm_fourcc.c | 1 +
> > > include/uapi/drm/drm_fourcc.h | 1 +
> > > 2 files changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > b/drivers/gpu/drm/drm_fourcc.c
> > > index be1d6aaef651..60752d0be9d8 100644
> > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > @@ -190,6 +190,7 @@ const struct drm_format_info
> > > *__drm_format_info(u32 format)
> > > { .format = DRM_FORMAT_UYVY,.depth
> > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1,
> > > .is_yuv = true },
> > > { .format = DRM_FORMAT_VYUY,.depth
> > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1,
> > > .is_yuv = true },
> > > { .format = DRM_FORMAT_AYUV,.depth
> > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1,
> > > .has_alpha = true, .is_yuv = true },
> > > + { .format = DRM_FORMAT_XYUV,.depth
> > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1,
> > > .is_yuv = true },
> > > };
> > >
> > > unsigned int i;
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > b/include/uapi/drm/drm_fourcc.h
> > > index 139632b87181..88d2e491f40c 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -151,6 +151,7 @@ extern "C" {
> > > #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U',
> > > 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > >
> > > #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U',
> > > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U',
> > > 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> > >
> > > /*
> > > * 2 plane RGB + A
> > > --
> > > 2.17.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> --
> Best Regards,
>
> Lisovskiy Stanislav
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm: Introduce new DRM_FORMAT_XYUV
Hi,
On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy wrote:
> v5: This is YUV444 packed format same as AYUV, but without alpha,
> as supported by i915.
>
> v6: Removed unneeded initializer for new XYUV format.
>
> v7: Added is_yuv field initialization according to latest
> drm_fourcc format structure initialization changes.
>
> v8: Edited commit message to be more clear about skl+, renamed
> PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
> doesn't support per-pixel alpha. Fixed minor code issues.
>
> v9: Moved DRM format check to proper place in intel_framebuffer_init.
>
> Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Alexandru Gheorghe
I'm planning of sending a new version with my series[1], do you think
this patch will get merged soon, or is there anything else that needs
to be done.
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index be1d6aaef651..60752d0be9d8 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -190,6 +190,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_XYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 139632b87181..88d2e491f40c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -151,6 +151,7 @@ extern "C" {
> #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U', 'V') /*
> [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
>
> /*
> * 2 plane RGB + A
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
Hi,
How is this going on, anything holding it back from getting merged ?
I'm interested in adding/using P010, [1]
Thank you,
Alex Gheorghe
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
On Thu, Aug 30, 2018 at 03:41:11PM +0300, Juha-Pekka Heikkila wrote:
> Add P010 definition, semi-planar yuv format where each component
> is 16 bits 10 msb containing color value. First come Y plane [10:6]
> followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
>
> Add P012 definition, semi-planar yuv format where each component
> is 16 bits 12 msb containing color value. First come Y plane [12:4]
> followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
>
> Add P016 definition, semi-planar yuv format where each component
> is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
> plane [16:16]
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 10 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 35c1e27..32e07a2 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 2ed46e9..daaabb1 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -178,6 +178,16 @@ extern "C" {
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
>
> /*
> + * 2 plane YCbCr
> + * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
> + * component xxx msb Y [xxx:16-xxx]
> + * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian [xxx:16-xxx:xxx:16-xxx]
> + */
> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> subsampled Cr:Cb plane, 10 bit per channel */
> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
> subsampled Cr:Cb plane, 12 bit per channel */
> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> subsampled Cr:Cb plane, 16 bit per channel */
> +
> +/*
> * 3 plane YCbCr
> * index 0: Y plane, [7:0] Y
> * index 1: Cb plane, [7:0] Cb
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/atomic: Initialise planes with opaque alpha values
On Thu, Sep 20, 2018 at 11:03:12AM +0100, Kieran Bingham wrote:
> Hi Alexandru,
>
> On 19/09/18 17:43, Alexandru-Cosmin Gheorghe wrote:
> > Hi Kieran,
> >
> >
> > On Wed, Sep 19, 2018 at 07:15:45PM +0300, Ville Syrjälä wrote:
> >> On Wed, Sep 19, 2018 at 04:56:58PM +0100, Kieran Bingham wrote:
> >>> Planes without an alpha property, using __drm_atomic_helper_plane_reset
> >>> will have their plane state alpha initialised as zero, which represents
> >>> a transparent alpha.
> >>>
> >>> If this value is then used for the plane, it may not be visible by
> >>> default, and thus doesn't represent a good initialisation state.
> >>>
> >>> Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE
> >>> unconditionally when the plane is reset.
> >>>
> >>> Signed-off-by: Kieran Bingham
> >>> ---
> >>> drivers/gpu/drm/drm_atomic_helper.c | 4 +---
> >>> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >>> b/drivers/gpu/drm/drm_atomic_helper.c
> >>> index 3cf1aa132778..e49b22381048 100644
> >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>> @@ -3569,9 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct
> >>> drm_plane *plane,
> >>> state->plane = plane;
> >>> state->rotation = DRM_MODE_ROTATE_0;
> >>>
> >>> - /* Reset the alpha value to fully opaque if it matters */
> >>> - if (plane->alpha_property)
> >>> - state->alpha = plane->alpha_property->values[1];
> >>> + state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> >>
> >> I can't come up with a solid excuse for not initializing it always.
> >>
> >> Reviewed-by: Ville Syrjälä
> >
> > Neither do I, so:
> > Reviewed-by: Alexandru Gheorghe
> >
> > And thanks again.
> >
> > I plan to push it tomorrow to drm-misc-next.
> >
> > Now, I've seen the plane_reset patches in the pull request for drm-next
> > 4.20, I wonder if someone could tell me what should I do to get this
> > patch on that train.
>
> I've submitted a separate patch for the rcar-du which enables the alpha
> property for the primary plane - and it incorporates a "Fixes:
> 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> instead of copying the logic")" tag.
>
> Technically that should be sufficient to get that fix into v4.19 I
> believe ...
plane_reset patches are not in v4.19, but in drm-next which as far as
I know will be sent for v4.20
>
> But if you feel that this patch should also be included - we could add
> the same tag to this patch, and get it queued up for v4.19 fixes?
Looking here
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/repositories.html#drm-misc-next
It seems that the last pull request for v4.20 of drm-misc-next will be
sent around rc6, so I think putting it in drm-misc-next will be enough
to get this with the rest of the plane_reset patch in v4.20, but just
to make sure I will double check with Sean on IRC.
>
> --
> Regards
>
> Kieran
>
>
> >
> >>
> >>> state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >>>
> >>> plane->state = state;
> >>> --
> >>> 2.17.1
> >>>
> >>> ___
> >>> dri-devel mailing list
> >>> dri-devel@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >> --
> >> Ville Syrjälä
> >> Intel
> >
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/atomic: Initialise planes with opaque alpha values
Hi Kieran, On Wed, Sep 19, 2018 at 07:15:45PM +0300, Ville Syrjälä wrote: > On Wed, Sep 19, 2018 at 04:56:58PM +0100, Kieran Bingham wrote: > > Planes without an alpha property, using __drm_atomic_helper_plane_reset > > will have their plane state alpha initialised as zero, which represents > > a transparent alpha. > > > > If this value is then used for the plane, it may not be visible by > > default, and thus doesn't represent a good initialisation state. > > > > Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE > > unconditionally when the plane is reset. > > > > Signed-off-by: Kieran Bingham > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index 3cf1aa132778..e49b22381048 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -3569,9 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane > > *plane, > > state->plane = plane; > > state->rotation = DRM_MODE_ROTATE_0; > > > > - /* Reset the alpha value to fully opaque if it matters */ > > - if (plane->alpha_property) > > - state->alpha = plane->alpha_property->values[1]; > > + state->alpha = DRM_BLEND_ALPHA_OPAQUE; > > I can't come up with a solid excuse for not initializing it always. > > Reviewed-by: Ville Syrjälä Neither do I, so: Reviewed-by: Alexandru Gheorghe And thanks again. I plan to push it tomorrow to drm-misc-next. Now, I've seen the plane_reset patches in the pull request for drm-next 4.20, I wonder if someone could tell me what should I do to get this patch on that train. > > > state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI; > > > > plane->state = state; > > -- > > 2.17.1 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v5 2/8] drm: Add Plane Degamma properties
Hi,
On Sun, Sep 16, 2018 at 01:45:25PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> v5: Added "Display Color Hardware Pipeline" flow to kernel
> documentation as suggested by "Ville Syrjala" and "Brian Starkey".
> Moved the property creation to drm_color_mgmt.c file to consolidate
> all color operations at one place.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Alexandru Gheorghe
> ---
> Documentation/gpu/drm-kms.rst | 90
> +
> drivers/gpu/drm/drm_atomic.c| 13 ++
> drivers/gpu/drm/drm_atomic_helper.c | 6 +++
> drivers/gpu/drm/drm_color_mgmt.c| 44 --
> include/drm/drm_plane.h | 24 ++
> 5 files changed, 174 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index f8f5bf1..253d546 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -551,12 +551,102 @@ Plane Composition Properties
> Color Management Properties
> ---
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware blocks
> +can help with this. Once the Data is blended, similar color processing
> +can be done on blended output using pipe color hardware blocks.
> +
> +DRM Properties have been created to define and expose all these
> +hardware blocks to userspace. A userspace application (compositor
> +or any color app) can use these interfaces and define policies to
> +efficiently use the display hardware for such color operations.
> +
> +Pipe Color Management Properties
> +-
> +
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :doc: overview
>
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :export:
>
> +Plane Color Management Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: Plane Color Properties
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: export
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d0478ab..e716614 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -857,6 +857,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> {
> struct drm_device *dev = plane->dev;
> struc
Re: [RFC v5 0/8] Add Plane Color Properties
On Sun, Sep 16, 2018 at 01:45:23PM +0530, Uma Shankar wrote: > This is how a typical display color hardware pipeline looks like: > +---+ > |RAM| > | +--++-++-+ | > | | FB 1 || FB 2 || FB N| | > | +--++-++-+ | > +---+ >| Plane Color Hardware Block | > ++ > | +---v-+ +---v---+ +---v--+ | > | | Plane A | | Plane B | | Plane N | | > | | DeGamma | | Degamma | | Degamma | | > | +---+-+ +---+---+ +---+--+ | > | | | || > | +---v-+ +---v---+ +---v--+ | > | |Plane A | | Plane B | | Plane N | | > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > | +---+-+ ++--+ ++-+ | > | | | | | > | +---v-+ +v--+ +v-+ | > | | Plane A | | Plane B | | Plane N | | > | | Gamma | | Gamma | | Gamma| | > | +---+-+ ++--+ ++-+ | > | | | | | > ++ > +--v--v---v---| > || || > || Pipe Blender|| > +++ > ||| > |+---v--+ | > || Pipe DeGamma| | > || | | > |+---+--+ | > ||Pipe Color | > |+---v--+ Hardware| > || Pipe CSC/CTM| | > || | | > |+---+--+ | > ||| > |+---v--+ | > || Pipe Gamma | | > || | | > |+---+--+ | > ||| > +-+ > | > v >Pipe Output > > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data, CSC used for gamut > conversion, and gamma used to again non-linearize data as per panel > supported color space. These can be utilize by user space to convert > planes from one format to another, one color space to another etc. > > Usersapce can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches just add the property interfaces and enable helper > functions. > > This series adds Intel Gen9 specific plane gamma feature. We can > build up and add other platform/hardware specific implementation > on top of this series > > Note: This is just to get a design feedback whether these interfaces > look ok. Based on community feedback on interfaces, we will implement > IGT tests to validate plane color features. This is un-tested currently. > > Userspace implementation using these properties have been done in drm > hwcomposer by "Alexandru-Cosmin Gheorghe alexandru-cosmin.gheor...@arm.com" > from ARM. A merge request has been opened by Alexandru for drm_hwcomposer, > implementing the property changes for the same. Please review that as well: > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/25 > Just heads-up I just pushed a v2 for that. > v2: Dropped legacy gamma table for plane as suggested by Maarten. Added > Gen9/BDW plane gamma feature and rebase on tot. > > v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision > entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul > comments and moved plane color properties to drm_plane instead of > mode_config. Added property documentation as suggested by Daniel, Vetter. > Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > > v4: Rebase > > v5: Added "Display Color Hardware Pipeline" flow to kernel > documentation as suggested by "Ville Syrjala" and "Brian Starkey". > Moved the property creation to drm_color_mgmt.c file to consolid
Re: [PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Hi Kieran,
On Mon, Sep 17, 2018 at 11:56:23AM +0100, Kieran Bingham wrote:
> Hi Alexandru,
>
> On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> > Hi Kieran,
> >
> > Sorry for that and thanks for getting to the bottom of it.
>
> No worries,
>
>
> > On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> >> Hi Laurent,
> >>
> >> I've looked through a bit further to try to understand this issue and I
> >> think I have identified a possible/probable cause.
> >>
> >> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
> >> DRM_BLEND_ALPHA_OPAQUE. (0x)
> >>
> >> After this commit, the __drm_atomic_helper_plane_reset() call will only
> >> set state->alpha to 0x if the alpha_property is set:
> >>
> >> if (plane->alpha_property)
> >> state->alpha = plane->alpha_property->values[1];
> >>
> >> Then the state->alpha value is always referenced in
> >> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
> >>
> >>
> >> We can see in rcar_du_planes_init(), that all OVERLAY planes are
> >> configured to have this propery with a call to
> >> drm_plane_create_alpha_property(&plane->plane); however - the PRIMARY
> >> plane is skipped over before setting this.
> >>
> >>
> >> I believe I recall seeing that the kms-test-planeposition.py
> >> successfully showed other planes which were not the back one (I'm now
> >> going from hazy memory of this afternoon - but I am fairly sure I saw this)
> >>
> >>
> >> This implies that the primary planes are being incorrectly configured -
> >> but the overlay planes are still functioning as expected.
> >>
> >> So I believe we could move the call to create the alpha property:
> >>drm_plane_create_alpha_property(&plane->plane);
> >>
> >> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue;
> >> statement.
> >>
> >
> > I don't see any reson why the primary plane shouldn't advertise an
> > alpha as well.
>
>
> OK - so I think we perhaps should make sure that we enable alpha for our
> primary plane in rcar-du.
>
>
> >> It may or may not make sense to have alpha blending support on the
> >> PRIMARY plane. At the risk of sounding silly - can we have anything else
> >> behind the PRIMARY plane ? (I doubt this, I don't think we have any
> >> extra layers hiding anywhere)
> >
> > I think the same question could apply to situations where PRIMARY is
> > disabled and you have just one OVERLAY plane enabled.
> >
> >>
> >> Otherwise, I think we would need to intercept the configuration of the
> >> alpha blending and make sure that all PRIMARY planes are configured to
> >> be fully opaque in our layers. I think this is happening in
> >> rcar_du_vsp_plane_setup().
> >>
> >> But rather than put in a conditional in there, I think I'd rather just
> >> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
> >> rcar_du_vsp_plane_reset() call and be done with it.
> >
> > I think you could do more and just go in
> > __drm_atomic_helper_plane_reset and always initializes plane->alpha
> > with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
>
> I think this sounds like a good thing too.
>
> Is DRM_BLEND_ALPHA_OPAQUE a suitable initial value for all of the other
> users of the helper ?
>
> I suspect the answer is yes, but I'll try to do a bit of digging through
> the other drivers tomorrow.
>
Yes, but it doesn't hurt for another pair of eyes to have a look.
> I presume we could then just remove the conditional check and always
> initialise to OPAQUE ...
>
> Or otherwise perhaps maybe initialising as an 'else' if no alpha
> property is provided.
>
> --
> Regards
>
> Kieran
>
>
>
>
>
>
> >>
> >> Anyway - just some musings and thoughts at this stage, we can
> >> investigate in more detail next week.
> >>
> >> --
> >> Regards
> >>
> >> Kieran
> >>
> >>
> >> On 14/09/18 21:09, Kieran Bingham wrote:
> >>> Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> >>> instead of copying the logic") causes a regression in the R-Car DU
> >>> display driver, and prev
Re: [PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Hi Kieran,
Sorry for that and thanks for getting to the bottom of it.
On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> Hi Laurent,
>
> I've looked through a bit further to try to understand this issue and I
> think I have identified a possible/probable cause.
>
> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
> DRM_BLEND_ALPHA_OPAQUE. (0x)
>
> After this commit, the __drm_atomic_helper_plane_reset() call will only
> set state->alpha to 0x if the alpha_property is set:
>
> if (plane->alpha_property)
> state->alpha = plane->alpha_property->values[1];
>
> Then the state->alpha value is always referenced in
> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
>
>
> We can see in rcar_du_planes_init(), that all OVERLAY planes are
> configured to have this propery with a call to
> drm_plane_create_alpha_property(&plane->plane); however - the PRIMARY
> plane is skipped over before setting this.
>
>
> I believe I recall seeing that the kms-test-planeposition.py
> successfully showed other planes which were not the back one (I'm now
> going from hazy memory of this afternoon - but I am fairly sure I saw this)
>
>
> This implies that the primary planes are being incorrectly configured -
> but the overlay planes are still functioning as expected.
>
> So I believe we could move the call to create the alpha property:
> drm_plane_create_alpha_property(&plane->plane);
>
> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue; statement.
>
I don't see any reson why the primary plane shouldn't advertise an
alpha as well.
> It may or may not make sense to have alpha blending support on the
> PRIMARY plane. At the risk of sounding silly - can we have anything else
> behind the PRIMARY plane ? (I doubt this, I don't think we have any
> extra layers hiding anywhere)
I think the same question could apply to situations where PRIMARY is
disabled and you have just one OVERLAY plane enabled.
>
> Otherwise, I think we would need to intercept the configuration of the
> alpha blending and make sure that all PRIMARY planes are configured to
> be fully opaque in our layers. I think this is happening in
> rcar_du_vsp_plane_setup().
>
> But rather than put in a conditional in there, I think I'd rather just
> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
> rcar_du_vsp_plane_reset() call and be done with it.
I think you could do more and just go in
__drm_atomic_helper_plane_reset and always initializes plane->alpha
with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
>
> Anyway - just some musings and thoughts at this stage, we can
> investigate in more detail next week.
>
> --
> Regards
>
> Kieran
>
>
> On 14/09/18 21:09, Kieran Bingham wrote:
> > Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> > instead of copying the logic") causes a regression in the R-Car DU
> > display driver, and prevents any output from being displayed.
> >
> > The display appears to function correctly but only a black screen is
> > ever visible.
> >
> > Revert the commit.
> >
> > Signed-off-by: Kieran Bingham
> >
> > ---
> >
> > Looking through the code, the reason for this issue isn't particularly
> > obvious - and will need some further exploration, which I can't look at
> > until Tuesday. So I'm posting this revert patch to
> >
> > A) Report the issue
> > B) Provide a temporary fix
> >
> > I suspect either the initial alpha value is not set correctly or setting
> >
> > state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >
> > causes some side effect perhaps. There's not much else that could be
> > different between the helper, and the original code.
> >
> > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
> > 2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > index 9e07758a755c..5c2462afe408 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > @@ -686,12 +686,14 @@ static void rcar_du_plane_reset(struct drm_plane
> > *plane)
> > if (state == NULL)
> > return;
> >
> > - __drm_atomic_helper_plane_reset(plane, &state->state);
> > -
> > state->hwindex = -1;
> > state->source = RCAR_DU_PLANE_MEMORY;
> > state->colorkey = RCAR_DU_COLORKEY_NONE;
> > state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> > +
> > + plane->state = &state->state;
> > + plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> > + plane->state->plane = plane;
> > }
> >
> > static int rcar_du_plane_atomic_set_property(struct drm_plane *plane,
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > index 4576119e..3170b126cfba 100644
> > --- a/drivers/
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
Hi, On Mon, Sep 17, 2018 at 08:27:18AM +, Lisovskiy, Stanislav wrote: > On Fri, 2018-09-14 at 14:59 +0000, Alexandru-Cosmin Gheorghe wrote: > > On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote: > > > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote: > > > > Hi, > > > > > > > > > -Original Message- > > > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org > > > > > ] On > > > > > Behalf > > > > > Of Lisovskiy, Stanislav > > > > > Sent: perjantai 14. syyskuuta 2018 17.31 > > > > > To: ville.syrj...@linux.intel.com > > > > > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville > > > > > > > > > intel.com>; > > > > > Heikkila, Juha-pekka ; dri- > > > > > de...@lists.freedesktop.org; Peres, Martin > > > > com> > > > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format > > > > > support > > > > > > > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, > > > > > > Stanislav > > > > > > wrote: > > > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy > > > > > > > wrote: > > > > > > > > Introduced new XYUV scan-in format for framebuffer and > > > > > > > > added > > > > > > > > support for it to i915(SkyLake+). > > > > > > > > > > > > > > > > Stanislav Lisovskiy (2): > > > > > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > > > > drivers/gpu/drm/i915/intel_display.c | 15 > > > > > > > > +++ > > > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > > > > This one left in order to get XYUV support. > > > > > > > > > > > > Did we figure out userspace for this? > > > > > > > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > > > > trying > > > > > > to add the same format with a different name? > > > > > > > > > > Currently for userspace we have VLC(checked with Juha-Pekka) > > > > > and > > > > > also IGT > > > > > test case. > > > > > > > > > > I think those guys were from ARM and they were adding also > > > > > support > > > > > for > > > > > XYUV. The only difference was that they called XYUV, like > > > > > XYUV > > > > > something. > > > > > Our patches were otherwise identical regarding drm_fourcc.c > > > > > part, I > > > > > don't > > > > > see their stuff merged, but I guess it really shouldn't matter, > > > > > who > > > > > does this > > > > > first. i915 specific part doesn't conflict with their stuff. To > > > > > be > > > > > honest, I forgot > > > > > the guy's name neither could find his email in my mailbox. > > > > > So hopefully somebody shows up here. > > > > > > > > Stan: > > > > Alexandru-Cosmin Gheorghe ? > > > > > > > > > > Exactly, found now. Thanks for the hint! > > > > Yes, that's me. > > Not a real conflict here, as long as your patches are ready to be > > merged feel free to do it and I will just rebase my series on top of > > that. > > I can change DRM_FORMAT_XYUV naming to DRM_FORMAT_XYUV also, so > that my patch series then is compatible with yours. That would be nice. Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best Regards, > > > > > > > > > > Lisovskiy Stanislav > > > > > ___ > > > > > Intel-gfx mailing list > > > > > intel-...@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > -- > > > Best Regards, > > > > > > Lisovskiy Stanislav > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > -- > Best Regards, > > Lisovskiy Stanislav -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote: > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote: > > Hi, > > > > > -Original Message- > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > > > Behalf > > > Of Lisovskiy, Stanislav > > > Sent: perjantai 14. syyskuuta 2018 17.31 > > > To: ville.syrj...@linux.intel.com > > > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville > > intel.com>; > > > Heikkila, Juha-pekka ; dri- > > > de...@lists.freedesktop.org; Peres, Martin > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support > > > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav > > > > wrote: > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > > > > > Introduced new XYUV scan-in format for framebuffer and added > > > > > > support for it to i915(SkyLake+). > > > > > > > > > > > > Stanislav Lisovskiy (2): > > > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > > This one left in order to get XYUV support. > > > > > > > > Did we figure out userspace for this? > > > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > > trying > > > > to add the same format with a different name? > > > > > > Currently for userspace we have VLC(checked with Juha-Pekka) and > > > also IGT > > > test case. > > > > > > I think those guys were from ARM and they were adding also support > > > for > > > XYUV. The only difference was that they called XYUV, like XYUV > > > something. > > > Our patches were otherwise identical regarding drm_fourcc.c part, I > > > don't > > > see their stuff merged, but I guess it really shouldn't matter, who > > > does this > > > first. i915 specific part doesn't conflict with their stuff. To be > > > honest, I forgot > > > the guy's name neither could find his email in my mailbox. > > > So hopefully somebody shows up here. > > > > Stan: > > Alexandru-Cosmin Gheorghe ? > > > > Exactly, found now. Thanks for the hint! Yes, that's me. Not a real conflict here, as long as your patches are ready to be merged feel free to do it and I will just rebase my series on top of that. > > > > > > > > > > > > > > -- > > > Best Regards, > > > > > > Lisovskiy Stanislav > > > ___ > > > Intel-gfx mailing list > > > intel-...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- > Best Regards, > > Lisovskiy Stanislav > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
On Tue, Sep 11, 2018 at 04:45:25PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 11, 2018 at 02:20:22PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > Hi Ville,
> >
> > On Tue, Sep 11, 2018 at 03:27:09PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 10, 2018 at 06:29:46PM +0100, Alexandru Gheorghe wrote:
> > > > DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> > > > to me, so try to clarify that with a bit of ascii graphics.
> > > >
> > > > Changes since v1:
> > > > - Move the ascii graphics in the kerneldoc where all plane
> > > > properties are already documented and make sure it's properly
> > > > rendered, suggestested by Daniel Vetter.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > drivers/gpu/drm/drm_blend.c | 22 ++
> > > > include/uapi/drm/drm_mode.h | 3 ++-
> > > > 2 files changed, 24 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > > index 402b62d3f072..92f75c5c93ac 100644
> > > > --- a/drivers/gpu/drm/drm_blend.c
> > > > +++ b/drivers/gpu/drm/drm_blend.c
> > > > @@ -101,6 +101,28 @@
> > > > * Without this property the rectangle is only scaled, but not
> > > > rotated or
> > > > * reflected.
> > > > *
> > > > + * Possbile values:
> > > > + *
> > > > + * "rotate-":
> > > > + * Signals that a drm plane is rotated degrees
> > > > in counter
> > > > + * clockwise direction.
> > > > + *
> > > > + * "reflect-":
> > > > + * Signals that the contents of a drm plane is reflected
> > > > along the
> > > > + * axis, in the same way as mirroring.
> > >
> > > What does "mirroring" mean? Feels like a circular definition here.
> > >
> >
> > That's why I added the pictures to make it more clear, what
> > reflect-x/reflect-y means.
>
> Sure. Doesn't really answer the quesiton I was asking. I propose just
> dropping the ", in the same way as mirroring." part. It provides no
> useful information that I can see.
I was hopping the picture answers to what exactly mirroring means in
this context, I have nothing against dropping that part from the
description.
>
> >
> > > Also the relationship between rotate and reflect is missing from these
> > > docs. The order matters, and I do believe we have it specified in some
> > > comment somewhere. Would be good to include it here as well.
> >
> > That's already explained in the documentation for
> > drm_plane_create_rotation_property(), which is already referred here.
> >
> > If you think that stuff should be duplicate here as well, it will have
> > to be done in another patch, because I already merged this patch in
> > drm-misc-next.
>
> I don't think having multiple different pieces of documentation for the
> same thing is a particularly good thing.
How do you propose to group this information?
>
> >
> > >
> > > > + *
> > > > + * reflect-x::
> > > > + *
> > > > + * |o || o|
> > > > + * | | -> | |
> > > > + * | v||v |
> > > > + *
> > > > + * reflect-y::
> > > > + *
> > > > + * |o || ^|
> > > > + * | | -> | |
> > > > + * | v||o |
> > > > + *
> > > > * zpos:
> > > > * Z position is set up with
> > > > drm_plane_create_zpos_immutable_property() and
> > > > * drm_plane_create_zpos_property(). It controls the visibility of
> > > > overlapping
> > > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > > index 8d67243952f4..d3e0fe31efc5 100644
> > > > --- a/include/uapi/drm/drm_mode.h
> > > > +++ b/include/uapi/drm/drm_mode.h
> > > > @@ -186,8 +186,9 @@ extern "C" {
> > > > /*
> > > > * DRM_MODE_REFLECT_
> > > > *
> > > > - * Signals that the contents of a drm plane is reflected in the
> > > > axis,
> > > > + * Signals that the contents of a drm plane is reflected along the
> > > > axis,
> > > > * in the same way as mirroring.
> > > > + * See kerneldoc chapter "Plane Composition Properties" for more
> > > > details.
> > > > *
> > > > * This define is provided as a convenience, looking up the property id
> > > > * using the name->prop id lookup is the preferred method.
> > > > --
> > > > 2.18.0
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> >
> > --
> > Cheers,
> > Alex G
>
> --
> Ville Syrjälä
> Intel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
Hi Ville,
On Tue, Sep 11, 2018 at 03:27:09PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 10, 2018 at 06:29:46PM +0100, Alexandru Gheorghe wrote:
> > DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> > to me, so try to clarify that with a bit of ascii graphics.
> >
> > Changes since v1:
> > - Move the ascii graphics in the kerneldoc where all plane
> > properties are already documented and make sure it's properly
> > rendered, suggestested by Daniel Vetter.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_blend.c | 22 ++
> > include/uapi/drm/drm_mode.h | 3 ++-
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index 402b62d3f072..92f75c5c93ac 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -101,6 +101,28 @@
> > * Without this property the rectangle is only scaled, but not rotated or
> > * reflected.
> > *
> > + * Possbile values:
> > + *
> > + * "rotate-":
> > + * Signals that a drm plane is rotated degrees in counter
> > + * clockwise direction.
> > + *
> > + * "reflect-":
> > + * Signals that the contents of a drm plane is reflected along the
> > + * axis, in the same way as mirroring.
>
> What does "mirroring" mean? Feels like a circular definition here.
>
That's why I added the pictures to make it more clear, what
reflect-x/reflect-y means.
> Also the relationship between rotate and reflect is missing from these
> docs. The order matters, and I do believe we have it specified in some
> comment somewhere. Would be good to include it here as well.
That's already explained in the documentation for
drm_plane_create_rotation_property(), which is already referred here.
If you think that stuff should be duplicate here as well, it will have
to be done in another patch, because I already merged this patch in
drm-misc-next.
>
> > + *
> > + * reflect-x::
> > + *
> > + * |o || o|
> > + * | | -> | |
> > + * | v||v |
> > + *
> > + * reflect-y::
> > + *
> > + * |o || ^|
> > + * | | -> | |
> > + * | v||o |
> > + *
> > * zpos:
> > * Z position is set up with drm_plane_create_zpos_immutable_property() and
> > * drm_plane_create_zpos_property(). It controls the visibility of
> > overlapping
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 8d67243952f4..d3e0fe31efc5 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -186,8 +186,9 @@ extern "C" {
> > /*
> > * DRM_MODE_REFLECT_
> > *
> > - * Signals that the contents of a drm plane is reflected in the
> > axis,
> > + * Signals that the contents of a drm plane is reflected along the
> > axis,
> > * in the same way as mirroring.
> > + * See kerneldoc chapter "Plane Composition Properties" for more details.
> > *
> > * This define is provided as a convenience, looking up the property id
> > * using the name->prop id lookup is the preferred method.
> > --
> > 2.18.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Describe pixel_blend_mode in drm_plane_state
Hi Sean,
On Fri, Aug 31, 2018 at 11:09:25AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
> found by kbuild test robot:
>
> htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member
> 'pixel_blend_mode' not described in 'drm_plane_state'
>
> Cc: Daniel Vetter
> Cc: Lowry Li
> Signed-off-by: Sean Paul
Reviewed-by: Alexandru Gheorghe
> ---
> include/drm/drm_plane.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 35ef64a9398b..16f5b66684ca 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -117,6 +117,13 @@ struct drm_plane_state {
>* details.
>*/
> u16 alpha;
> +
> + /**
> + * @pixel_blend_mode:
> + * The alpha blending equation selection, describing how the pixels from
> + * the current plane are composited with the background. Value can be
> + * one of DRM_MODE_BLEND_*
> + */
> uint16_t pixel_blend_mode;
>
> /**
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Mon, Sep 03, 2018 at 09:26:24AM +0200, Daniel Vetter wrote: > On Fri, Aug 31, 2018 at 05:26:37PM +0100, Alexandru-Cosmin Gheorghe wrote: > > Hi, > > > > On Fri, Aug 31, 2018 at 05:12:24PM +0200, Daniel Vetter wrote: > > > On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote: > > > > On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote: > > > > > On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe > > > > > wrote: > > > > > > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote: > > > > > > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe > > > > > > > wrote: > > > > > > > > The previous patch added tile_w and tile_h, which represent the > > > > > > > > horizontal and vertical sizes of a tile. > > > > > > > > > > > > > > > > This one uses that to plumb through drm core in order to be > > > > > > > > able to > > > > > > > > handle linear tile formats without the need for drivers to roll > > > > > > > > up > > > > > > > > their own implementation. > > > > > > > > > > > > > > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind > > > > > > > > which > > > > > > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in > > > > > > > > average 2 > > > > > > > > bytes per pixel and where tiles are laid out in a linear manner. > > > > > > > > > > > > > > > > Now what are the restrictions: > > > > > > > > > > > > > > > > 1. Pitch in bytes is expected to cover at least tile_h * width > > > > > > > > in > > > > > > > > pixels. Due to this the places where the pitch is checked/used > > > > > > > > need to > > > > > > > > be updated to take into consideration the tile_w, tile_h and > > > > > > > > tile_size. > > > > > > > > tile_size = cpp * tile_w * tile_h > > > > > > > > > > > > > > > > 2. When doing source cropping plane_src_x/y need to be a > > > > > > > > multiple of > > > > > > > > tile_w/tile_h and we need to take into consideration the > > > > > > > > tile_w/tile_h > > > > > > > > when computing the start address. > > > > > > > > > > > > > > > > For all non-tiled formats the tile_w and tile_h will be 1, so > > > > > > > > if I > > > > > > > > didn't miss anything nothing should change. > > > > > > > > > > > > > > > > Regarding multi-planar linear tile formats, I'm not sure how > > > > > > > > those > > > > > > > > should be handle I kind of assumed that tile_h/tile_w will have > > > > > > > > to be > > > > > > > > divided by horizontal/subsampling. Anyway, I think it's best to > > > > > > > > just > > > > > > > > put an warning in there and handle it when someone tries to add > > > > > > > > support for them. > > > > > > > > > > > > > > > > Signed-off-by: Alexandru Gheorghe > > > > > > > > > > > > > > > > --- > > > > > > > > drivers/gpu/drm/drm_atomic.c | 8 +++ > > > > > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 - > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 52 > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_framebuffer.c| 19 +-- > > > > > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++-- > > > > > > > > include/drm/drm_fourcc.h | 2 + > > > > > > > > 6 files changed, 94 insertions(+), 8 deletions(-) > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c > > > > > > > > b/drivers/gpu/drm/drm_atomic.c > > > > > >
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
Hi,
On Fri, Aug 31, 2018 at 05:12:24PM +0200, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote:
> > On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > > > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > > > The previous patch added tile_w and tile_h, which represent the
> > > > > > horizontal and vertical sizes of a tile.
> > > > > >
> > > > > > This one uses that to plumb through drm core in order to be able to
> > > > > > handle linear tile formats without the need for drivers to roll up
> > > > > > their own implementation.
> > > > > >
> > > > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average
> > > > > > 2
> > > > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > > > >
> > > > > > Now what are the restrictions:
> > > > > >
> > > > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > > > pixels. Due to this the places where the pitch is checked/used need
> > > > > > to
> > > > > > be updated to take into consideration the tile_w, tile_h and
> > > > > > tile_size.
> > > > > > tile_size = cpp * tile_w * tile_h
> > > > > >
> > > > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > > > tile_w/tile_h and we need to take into consideration the
> > > > > > tile_w/tile_h
> > > > > > when computing the start address.
> > > > > >
> > > > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > > > didn't miss anything nothing should change.
> > > > > >
> > > > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > > > should be handle I kind of assumed that tile_h/tile_w will have to
> > > > > > be
> > > > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > > > put an warning in there and handle it when someone tries to add
> > > > > > support for them.
> > > > > >
> > > > > > Signed-off-by: Alexandru Gheorghe
> > > > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > > >
> > > > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > > > include/drm/drm_fourcc.h | 2 +
> > > > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > > > drm_plane *plane,
> > > > > > return -ENOSPC;
> > > > > > }
> > > > > >
> > > > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > > > not meet tile restrictions",
> > > > > > +plane->base.id, plane->name);
> > > > > > + return -EINVAL;
> > > > > > + }
> > > &g
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 04:48:45PM +0100, Brian Starkey wrote:
> Hi Alex,
>
> On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
> >When doing suspend/resume drivers usually use the
> >drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> >state and then re-comitting it.
> >
> >The problem is that drm_crtc_state has a bool field called
> >color_mgmt_changed, which mali-dp and other drivers uses it to detect
> >if coefficients need to be reprogrammed, but that never happens
> >because the saved state has color_mgmt_changed set to 0.
> >
> >Fix that by setting color_mgmt_changed to true in
> >drm_atomic_helper_check_modeset when at least one of gamma_lut,
> >degamma_lut, ctm is different between the new and the old crtc state.
> >
> >Also, this makes unnecessary the setting of color_mgmt_changed in
> >places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
> >
> >Changes since v2:
> > - Instead of setting color_mgmt_changed in commit_duplicated_set
> > just set it in check_modeset and clean up other place where it was
> > set, suggested by Maarten Lankhorst.
> >
> >Signed-off-by: Alexandru Gheorghe
> >---
> >drivers/gpu/drm/drm_atomic.c| 12 +++-
> >drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> >drivers/gpu/drm/drm_fb_helper.c | 1 -
> >3 files changed, 10 insertions(+), 11 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >index d0478abc01bd..9bcada3c299e 100644
> >--- a/drivers/gpu/drm/drm_atomic.c
> >+++ b/drivers/gpu/drm/drm_atomic.c
> >@@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > drm_property_blob_put(mode);
> > return ret;
> > } else if (property == config->degamma_lut_property) {
> >-ret = drm_atomic_replace_property_blob_from_id(dev,
> >+return drm_atomic_replace_property_blob_from_id(dev,
> > &state->degamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> >-state->color_mgmt_changed |= replaced;
> >-return ret;
> > } else if (property == config->ctm_property) {
> >-ret = drm_atomic_replace_property_blob_from_id(dev,
> >+return drm_atomic_replace_property_blob_from_id(dev,
> > &state->ctm,
> > val,
> > sizeof(struct drm_color_ctm), -1,
> > &replaced);
> >-state->color_mgmt_changed |= replaced;
> >-return ret;
> > } else if (property == config->gamma_lut_property) {
> >-ret = drm_atomic_replace_property_blob_from_id(dev,
> >+return drm_atomic_replace_property_blob_from_id(dev,
> > &state->gamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> >-state->color_mgmt_changed |= replaced;
> >-return ret;
>
> Looks like 'replaced' is now unused, so you can remove it.
It's needed as an argument for
drm_atomic_replace_property_blob_from_id, and the prototype of the
function makes sense to me.
>
> Cheers,
> -Brian
>
> > } else if (property == config->prop_out_fence_ptr) {
> > s32 __user *fence_ptr = u64_to_user_ptr(val);
> >
> >diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >b/drivers/gpu/drm/drm_atomic_helper.c
> >index 2c23a48482da..fe22e1ad468a 100644
> >--- a/drivers/gpu/drm/drm_atomic_helper.c
> >+++ b/drivers/gpu/drm/drm_atomic_helper.c
> >@@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >
> > return -EINVAL;
> > }
> >+if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
> >||
> >+new_crtc_state->ctm != old_crtc_state->ctm ||
> >+new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
> >+DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
> >changed\n",
> >+ crtc->base.id, crtc->name);
> >+new_crtc_state->color_mgmt_changed = true;
> >+}
> > }
> >
> > ret = handle_conflicting_encoders(state, false);
> >@@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> >*crtc,
> > replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> >-crtc_state->color_mgmt_changed |= replaced;
> >
> > ret = drm_atomic_commit(state);
> >
> >diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >b/driver
Re: [PATCH v2] drm: Fix crtc color management when doing suspend/resume
On Tue, Aug 28, 2018 at 06:46:07PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 28, 2018 at 04:33:20PM +0100, Alexandru Gheorghe wrote:
> > When doing suspend/resume drivers usually use the
> > drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> > state and then re-comitting it.
> >
> > The problem is that drm_crtc_state has a bool field called
> > color_mgmt_changed, which mali-dp and other drivers uses it to detect
> > if coefficients need to be reprogrammed, but that never happens
> > because the saved state has color_mgmt_changed set to 0.
> >
> > Fix that by setting color_mgmt_changed to true in
> > drm_atomic_helper_check_modeset when at least one of gamma_lut,
> > degamma_lut, ctm is different between the new and the old crtc state.
> >
> > Also, this makes unnecessary the setting of color_mgmt_changed in
> > places where gamma_lut/degamma_lut/ctm are set in the new crtc_state.
>
> Do all current drivers actually call drm_atomic_helper_check_modeset()
> for every commit?
Yes, all drivers that use color_mgmt_changed either call directly
drm_atomic_helper_check_modeset or they use drm_atomic_helper_check
which calls drm_atomic_helper_check_modeset.
>
> >
> > Changes since v2:
> > - Instead of setting color_mgmt_changed in commit_duplicated_set
> > just set it in check_modeset and clean up other place where it was
> > set, suggested by Maarten Lankhorst.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c| 12 +++-
> > drivers/gpu/drm/drm_atomic_helper.c | 8 +++-
> > drivers/gpu/drm/drm_fb_helper.c | 1 -
> > 3 files changed, 10 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index d0478abc01bd..9bcada3c299e 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -554,29 +554,23 @@ int drm_atomic_crtc_set_property(struct drm_crtc
> > *crtc,
> > drm_property_blob_put(mode);
> > return ret;
> > } else if (property == config->degamma_lut_property) {
> > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > + return drm_atomic_replace_property_blob_from_id(dev,
> > &state->degamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> > - state->color_mgmt_changed |= replaced;
> > - return ret;
> > } else if (property == config->ctm_property) {
> > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > + return drm_atomic_replace_property_blob_from_id(dev,
> > &state->ctm,
> > val,
> > sizeof(struct drm_color_ctm), -1,
> > &replaced);
> > - state->color_mgmt_changed |= replaced;
> > - return ret;
> > } else if (property == config->gamma_lut_property) {
> > - ret = drm_atomic_replace_property_blob_from_id(dev,
> > + return drm_atomic_replace_property_blob_from_id(dev,
> > &state->gamma_lut,
> > val,
> > -1, sizeof(struct drm_color_lut),
> > &replaced);
> > - state->color_mgmt_changed |= replaced;
> > - return ret;
> > } else if (property == config->prop_out_fence_ptr) {
> > s32 __user *fence_ptr = u64_to_user_ptr(val);
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 2c23a48482da..fe22e1ad468a 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -611,6 +611,13 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >
> > return -EINVAL;
> > }
> > + if (new_crtc_state->degamma_lut != old_crtc_state->degamma_lut
> > ||
> > + new_crtc_state->ctm != old_crtc_state->ctm ||
> > + new_crtc_state->gamma_lut != old_crtc_state->gamma_lut) {
> > + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] color management
> > changed\n",
> > +crtc->base.id, crtc->name);
> > + new_crtc_state->color_mgmt_changed = true;
> > + }
> > }
> >
> > ret = handle_conflicting_encoders(state, false);
> > @@ -3947,7 +3954,6 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > drm_crtc *crtc,
> > replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> > - crtc_state->color_mgmt_changed |= replaced
Re: [PATCH 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
Hi Swati,
On Mon, Aug 27, 2018 at 12:17:45PM +0530, Swati Sharma wrote:
> From: Vidya Srinivas
>
> The following pixel formats are packed format that follows 4:2:2
> chroma sampling. For memory represenation each component is
> allocated 16 bits each. Thus each pixel occupies a DWORD.
>
> Y210: Valid data occupies MSB 10 bits.
> LSB 6 bits are filled with zeroes.
> Y212: Valid data occupies MSB 12 bits.
> LSB 4 bits are filled with zeroes.
> Y216: Valid data occupies 16 bits,
> doesn't require any padding bits.
>
> First 16 bits stores the Y value and the next 16 bits stores one
> of the chroma samples alternatively. The first luma sample will
> be accompanied by first U sample and second luma sample is
> accompanied by the first V sample.
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 35c1e27..4bf04a5 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y210,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_Y212,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1 },
> + { .format = DRM_FORMAT_Y216,.depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1 },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 2ed46e9..6a03e6d 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -149,6 +149,10 @@
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>
> +#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
> Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
> +#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
> Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
> +#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
> Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
I don't think this comments reflect very well the actual layout of the
color planes, I think you need to describe the padding as well.
Just looking at the comments without reading the commit message you
could easily assume that the padding happens is in the [63:40] bits.
> +
> /*
> * 2 plane RGB + A
> * index 0 = RGB plane, same format as the corresponding non _A8 format has
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix crtc color management when doing suspend/resume
Hi,
On Fri, Aug 24, 2018 at 09:51:03AM +0200, Maarten Lankhorst wrote:
> Op 23-08-18 om 17:11 schreef Alexandru Gheorghe:
> > When doing suspend/resume drivers usually use the
> > drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
> > state and then re-comitting it.
> >
> > The problems is that drm_crtc_state has a bool field called
> > color_mgmt_changed, which mali-dp and other drivers uses it to detect
> > if coefficients need to be reprogrammed, but that never happens
> > because the save state has color_mgmt_changed set to 0.
> >
> > Fix that by setting color_mgmt_changed to true if the crtc duplicated
> > state differs from the reset state.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 6dd5036545ec..e88aa62bc822 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3196,8 +3196,13 @@ int drm_atomic_helper_commit_duplicated_state(struct
> > drm_atomic_state *state,
> > for_each_new_plane_in_state(state, plane, new_plane_state, i)
> > state->planes[i].old_state = plane->state;
> >
> > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > state->crtcs[i].old_state = crtc->state;
> > + new_crtc_state->color_mgmt_changed =
> > + new_crtc_state->degamma_lut != crtc->state->degamma_lut
> > ||
> > + new_crtc_state->ctm != crtc->state->ctm ||
> > + new_crtc_state->gamma_lut != crtc->state->gamma_lut;
> Don't look at $obj->state please, use for_each_oldnew.
>
> But it looks like we should set color_mgmt_changed in
> drm_atomic_helper_check_planes(),
> (or check_modeset if we want to know color_mgmt_changed from the planes
> atomic_check() too.
> The existing places that set color_mgmt_changed should be removed, because
> that check is now done in a single place. :)
drm_atomic_helper_check_modeset was the first candidate for me as
well, I think that makes more sense than
drm_atomic_helper_check_planes, don't you think ?
> > for_each_new_connector_in_state(state, connector, new_conn_state, i)
> > state->connectors[i].old_state = connector->state;
>
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 08:25:46PM +0300, Ville Syrjälä wrote: > On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote: > > On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote: > > > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote: > > > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe > > > > wrote: > > > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote: > > > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe > > > > >> wrote: > > > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote: > > > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe > > > > >> > > wrote: > > > > >> > > > The previous patch added tile_w and tile_h, which represent the > > > > >> > > > horizontal and vertical sizes of a tile. > > > > >> > > > > > > > >> > > > This one uses that to plumb through drm core in order to be > > > > >> > > > able to > > > > >> > > > handle linear tile formats without the need for drivers to > > > > >> > > > roll up > > > > >> > > > their own implementation. > > > > >> > > > > > > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind > > > > >> > > > which > > > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in > > > > >> > > > average 2 > > > > >> > > > bytes per pixel and where tiles are laid out in a linear > > > > >> > > > manner. > > > > >> > > > > > > > >> > > > Now what are the restrictions: > > > > >> > > > > > > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width > > > > >> > > > in > > > > >> > > > pixels. Due to this the places where the pitch is checked/used > > > > >> > > > need to > > > > >> > > > be updated to take into consideration the tile_w, tile_h and > > > > >> > > > tile_size. > > > > >> > > > tile_size = cpp * tile_w * tile_h > > > > >> > > > > > > > >> > > > 2. When doing source cropping plane_src_x/y need to be a > > > > >> > > > multiple of > > > > >> > > > tile_w/tile_h and we need to take into consideration the > > > > >> > > > tile_w/tile_h > > > > >> > > > when computing the start address. > > > > >> > > > > > > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so > > > > >> > > > if I > > > > >> > > > didn't miss anything nothing should change. > > > > >> > > > > > > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how > > > > >> > > > those > > > > >> > > > should be handle I kind of assumed that tile_h/tile_w will > > > > >> > > > have to be > > > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best > > > > >> > > > to just > > > > >> > > > put an warning in there and handle it when someone tries to add > > > > >> > > > support for them. > > > > >> > > > > > > > >> > > > Signed-off-by: Alexandru Gheorghe > > > > >> > > > > > > > >> > > > --- > > > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++ > > > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 - > > > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52 > > > > >> > > > > > > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +-- > > > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++-- > > > > >> > > > include/drm/d
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > The previous patch added tile_w and tile_h, which represent the
> > horizontal and vertical sizes of a tile.
> >
> > This one uses that to plumb through drm core in order to be able to
> > handle linear tile formats without the need for drivers to roll up
> > their own implementation.
> >
> > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > bytes per pixel and where tiles are laid out in a linear manner.
> >
> > Now what are the restrictions:
> >
> > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > pixels. Due to this the places where the pitch is checked/used need to
> > be updated to take into consideration the tile_w, tile_h and
> > tile_size.
> > tile_size = cpp * tile_w * tile_h
> >
> > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > when computing the start address.
> >
> > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > didn't miss anything nothing should change.
> >
> > Regarding multi-planar linear tile formats, I'm not sure how those
> > should be handle I kind of assumed that tile_h/tile_w will have to be
> > divided by horizontal/subsampling. Anyway, I think it's best to just
> > put an warning in there and handle it when someone tries to add
> > support for them.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c | 8 +++
> > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > drivers/gpu/drm/drm_fourcc.c | 52
> > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > include/drm/drm_fourcc.h | 2 +
> > 6 files changed, 94 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e11e2e..7a3e893a4cd1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > return -ENOSPC;
> > }
> >
> > + /* Make sure source coordinates are a multiple of tile sizes */
> > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > tile restrictions",
> > +plane->base.id, plane->name);
> > + return -EINVAL;
> > + }
> > +
> > if (plane_switching_crtc(state->state, plane, state)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > plane->base.id, plane->name);
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > index 47e0e2f6642d..4d8052adce67 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> > *fb,
> > struct drm_gem_cma_object *obj;
> > dma_addr_t paddr;
> > u8 h_div = 1, v_div = 1;
> > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> >
> > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > if (!obj)
> > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > drm_framebuffer *fb,
> > v_div = fb->format->vsub;
> > }
> >
> > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > + / h_div;
> > + /*
> > +* For tile formats pitches are expected to cover at least
> > +* width * tile_h pixels
> > +*/
> > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
> >
> > return paddr;
> > }
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index f55cd93ba2d0..d6c9c5aa4036 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t
> > format, int plane)
> > return height / info->vsub;
> > }
> > EXPORT_SYMBOL(drm_format_plane_height);
> > +
> > +/**
> > + * drm_format_tile_width - width of a tile for tile formats, should be 1
> > for all
> > + * non-tiled formats.
> > + * @format: pixel format
> > + * @plane: plane index
> > + *
> > + * Returns:
> > + * The width of a tile, depending on the plane index and horizontal
> > sub-sampling
> > + */
> > +uin
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote: > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote: > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe > > wrote: > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote: > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe > > >> wrote: > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote: > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote: > > >> > > > The previous patch added tile_w and tile_h, which represent the > > >> > > > horizontal and vertical sizes of a tile. > > >> > > > > > >> > > > This one uses that to plumb through drm core in order to be able to > > >> > > > handle linear tile formats without the need for drivers to roll up > > >> > > > their own implementation. > > >> > > > > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind > > >> > > > which > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in > > >> > > > average 2 > > >> > > > bytes per pixel and where tiles are laid out in a linear manner. > > >> > > > > > >> > > > Now what are the restrictions: > > >> > > > > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in > > >> > > > pixels. Due to this the places where the pitch is checked/used > > >> > > > need to > > >> > > > be updated to take into consideration the tile_w, tile_h and > > >> > > > tile_size. > > >> > > > tile_size = cpp * tile_w * tile_h > > >> > > > > > >> > > > 2. When doing source cropping plane_src_x/y need to be a multiple > > >> > > > of > > >> > > > tile_w/tile_h and we need to take into consideration the > > >> > > > tile_w/tile_h > > >> > > > when computing the start address. > > >> > > > > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I > > >> > > > didn't miss anything nothing should change. > > >> > > > > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how those > > >> > > > should be handle I kind of assumed that tile_h/tile_w will have to > > >> > > > be > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best to > > >> > > > just > > >> > > > put an warning in there and handle it when someone tries to add > > >> > > > support for them. > > >> > > > > > >> > > > Signed-off-by: Alexandru Gheorghe > > >> > > > > > >> > > > --- > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++ > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 - > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52 > > >> > > > > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +-- > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++-- > > >> > > > include/drm/drm_fourcc.h | 2 + > > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-) > > >> > > > > > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c > > >> > > > b/drivers/gpu/drm/drm_atomic.c > > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644 > > >> > > > --- a/drivers/gpu/drm/drm_atomic.c > > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c > > >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct > > >> > > > drm_plane *plane, > > >> > > > return -ENOSPC; > > >> > > > } > > >> > > > > > >> > > > + /* Make sure source coordinates are a multiple of tile > > >> > > > sizes */ > > >> > > > + if ((state->src_x >> 16) % sta
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > The previous patch added tile_w and tile_h, which represent the
> > > > horizontal and vertical sizes of a tile.
> > > >
> > > > This one uses that to plumb through drm core in order to be able to
> > > > handle linear tile formats without the need for drivers to roll up
> > > > their own implementation.
> > > >
> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > >
> > > > Now what are the restrictions:
> > > >
> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > pixels. Due to this the places where the pitch is checked/used need to
> > > > be updated to take into consideration the tile_w, tile_h and
> > > > tile_size.
> > > > tile_size = cpp * tile_w * tile_h
> > > >
> > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > > > when computing the start address.
> > > >
> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > didn't miss anything nothing should change.
> > > >
> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > should be handle I kind of assumed that tile_h/tile_w will have to be
> > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > put an warning in there and handle it when someone tries to add
> > > > support for them.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > include/drm/drm_fourcc.h | 2 +
> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > drm_plane *plane,
> > > > return -ENOSPC;
> > > > }
> > > >
> > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > not meet tile restrictions",
> > > > +plane->base.id, plane->name);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Feels rather wrong to me to put such hardware specific limitations into
> > > the core.
> >
> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > work.
>
> If that guy is supposed to give you a tile aligned address then it could
> just do that and leave it up to the driver to deal with the remainder of
> the coordinates?
>
> >
> > An alternative, would be to include it in the driver and put an WARN
> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > src_x/src_y tile multiples.
> >
> > What do you think about that ?
> >
> > >
> > > > +
> > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > directly\n",
> > > &
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > The previous patch added tile_w and tile_h, which represent the
> > horizontal and vertical sizes of a tile.
> >
> > This one uses that to plumb through drm core in order to be able to
> > handle linear tile formats without the need for drivers to roll up
> > their own implementation.
> >
> > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > bytes per pixel and where tiles are laid out in a linear manner.
> >
> > Now what are the restrictions:
> >
> > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > pixels. Due to this the places where the pitch is checked/used need to
> > be updated to take into consideration the tile_w, tile_h and
> > tile_size.
> > tile_size = cpp * tile_w * tile_h
> >
> > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > when computing the start address.
> >
> > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > didn't miss anything nothing should change.
> >
> > Regarding multi-planar linear tile formats, I'm not sure how those
> > should be handle I kind of assumed that tile_h/tile_w will have to be
> > divided by horizontal/subsampling. Anyway, I think it's best to just
> > put an warning in there and handle it when someone tries to add
> > support for them.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c | 8 +++
> > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > drivers/gpu/drm/drm_fourcc.c | 52
> > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > include/drm/drm_fourcc.h | 2 +
> > 6 files changed, 94 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e11e2e..7a3e893a4cd1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > return -ENOSPC;
> > }
> >
> > + /* Make sure source coordinates are a multiple of tile sizes */
> > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > tile restrictions",
> > +plane->base.id, plane->name);
> > + return -EINVAL;
> > + }
>
> Feels rather wrong to me to put such hardware specific limitations into
> the core.
Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
work.
An alternative, would be to include it in the driver and put an WARN
in drm_fb_cma_get_gem_addr in case someone else uses it with a
src_x/src_y tile multiples.
What do you think about that ?
>
> > +
> > if (plane_switching_crtc(state->state, plane, state)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > plane->base.id, plane->name);
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > index 47e0e2f6642d..4d8052adce67 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> > *fb,
> > struct drm_gem_cma_object *obj;
> > dma_addr_t paddr;
> > u8 h_div = 1, v_div = 1;
> > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> >
> > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > if (!obj)
> > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > drm_framebuffer *fb,
> > v_div = fb->format->vsub;
> > }
> >
> > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > + / h_div;
> > + /*
> > +* For tile formats pitches are expected to cover at least
> > +* width * tile_h pixels
> > +*/
> > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
> >
> > return paddr;
> > }
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index f55cd93ba2d0..d6c9c5aa4036 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t
> > format, int plane)
> > return height / info->vsub;
> > }
> > EX
Re: [PATCH v2 1/5] drm/fourcc: Add new fourcc for malidp uncompressed formats
Hi,
On Wed, Aug 22, 2018 at 01:39:16PM +0300, Juha-Pekka Heikkilä wrote:
>
> On 22.08.2018 12:40, Daniel Vetter wrote:
> >On Tue, Aug 21, 2018 at 8:30 PM, Alexandru Gheorghe
> > wrote:
> >>Malidp implements a number of yuv buffer formats which are not
> >>currently described in drm_fourcc.h.
> >>This adds those definitions and describes their memory layout.
> >>
> >>Signed-off-by: Alexandru Gheorghe
> >
> >We're working on adding at least some of these for i915 too. Adding
> >the relevant people, to make sure we end up with agreeing drm_fourcc.h
> >codes.
> >
> >JP, Swati, please take a look at this and review.
> >
> >Thanks, Daniel
> >
> >>---
> >> drivers/gpu/drm/drm_fourcc.c | 7 +++
> >> include/uapi/drm/drm_fourcc.h | 27 ++-
> >> 2 files changed, 33 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >>index 35c1e2742c27..18bb960e9943 100644
> >>--- a/drivers/gpu/drm/drm_fourcc.c
> >>+++ b/drivers/gpu/drm/drm_fourcc.c
> >>@@ -173,6 +173,13 @@ const struct drm_format_info *__drm_format_info(u32
> >>format)
> >> { .format = DRM_FORMAT_UYVY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true
> >> },
> >> { .format = DRM_FORMAT_VYUY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true
> >> },
> >> { .format = DRM_FORMAT_AYUV,.depth = 0,
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha =
> >> true, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_XYUV,.depth = 0,
> >>.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
> >>.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
> >>.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .has_alpha =
> >>true, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_X0L0,.depth = 0,
> >>.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
> >>.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .has_alpha =
> >>true, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_X0L2,.depth = 0,
> >>.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_P010,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >> };
> >>
> >> unsigned int i;
> >>diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >>index 21c50b39596f..5e01fbcd7a30 100644
> >>--- a/include/uapi/drm/drm_fourcc.h
> >>+++ b/include/uapi/drm/drm_fourcc.h
> >>@@ -141,13 +141,31 @@ extern "C" {
> >> #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
> >> R:G:B:A 10:10:10:2 little endian */
> >> #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
> >> B:G:R:A 10:10:10:2 little endian */
> >>
> >>-/* packed YCbCr */
> >>+/* packed YCbCr422 */
> >> #define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
> >> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> >> #define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
> >> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> >> #define DRM_FORMAT_UYVYfourcc_code('U', 'Y', 'V', 'Y') /*
> >> [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian */
> >> #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
> >> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >>
> >>+/* packed YCbCr444 */
> >> #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
> >> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> >>+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
> >>X:Y:Cb:Cr 8:8:8:8 little endian */
> >>+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
> >>X:Cr:Y:Cb 2:10:10:10 little endian */
> >>+
> >>+/*
> >>+ * packed YCbCr420 2x2 tiled formats
> >>+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
> >>+ */
> >>+
> >>+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
> >>1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
> >>+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
> >>+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
> >>1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
> >>+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
> >>+
> >>+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10
> >>little endian */
> >>+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
> >>+/*
Re: [PATCH] drm/fourcc: Add DOC: overview comment
On Tue, Aug 21, 2018 at 06:51:26PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
> > There's a number of things which haven't previously been documented
> > around the usage of format modifiers. Capture the current
> > understanding in an overview comment and add it to the rst
> > documentation.
> >
> > Ideally, the generated documentation would also include documentation
> > of all of the #defines, but the kernel-doc system doesn't currently
> > support kernel-doc comments on #define constants.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Brian Starkey
> > ---
> > Documentation/gpu/drm-kms.rst | 6 ++
> > include/uapi/drm/drm_fourcc.h | 36
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 1dffd1ac4cd4..1dd9f4824d3b 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -322,6 +322,12 @@ Frame Buffer Functions Reference
> > DRM Format Handling
> > ===
> >
> > +.. kernel-doc:: include/uapi/drm/drm_fourcc.h
> > + :doc: overview
> > +
> > +Format Functions Reference
> > +--
> > +
> > .. kernel-doc:: include/drm/drm_fourcc.h
> > :internal:
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 894fa2da32fd..3f6c0b499323 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -30,6 +30,42 @@
> > extern "C" {
> > #endif
> >
> > +/**
> > + * DOC: overview
> > + *
> > + * In the DRM subsystem, framebuffer pixel formats are described using the
> > + * fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to
> > the
> > + * fourcc code, a Format Modifier may optionally be provided, in order to
> > + * further describe the buffer's format - for example tiling or
> > compression.
> > + *
> > + * Format Modifiers
> > + *
> > + *
> > + * Format modifiers are used in conjunction with a fourcc code, forming a
> > + * unique fourcc:modifier pair. This format:modifier pair must fully
> > define the
> > + * format and data layout of the buffer, and should be the only way to
> > describe
> > + * that particular buffer.
> > + *
> > + * Having multiple fourcc:modifier pairs which describe the same layout
> > should
> > + * be avoided, as such aliases run the risk of different drivers exposing
> > + * different names for the same data format, forcing userspace to
> > understand
> > + * that they are aliases.
> > + *
> > + * Format modifiers may change any property of the buffer, including the
> > number
> > + * of planes and/or the required allocation size. Format modifiers are
> > + * vendor-namespaced, and as such the relationship between a fourcc code
> > and a
> > + * modifier is specific to the modifer being used. For example, some
> > modifiers
> > + * may preserve meaning - such as number of planes - from the fourcc code,
> > + * whereas others may not.
> > + *
> > + * Vendors are encouraged to document their modifier usage in as much
> > detail as
>
> I'd go with a slightly stronger "... should document ..." but either way:
>
> Reviewed-by: Daniel Vetter
>
> I'll leave pushing to one of the arm committers for drm-misc.
> -Daniel
Done.
>
> > + * possible, to ensure maximum compatibility across devices, drivers and
> > + * applications.
> > + *
> > + * The authoritative list of format modifier codes is found in
> > + * `include/uapi/drm/drm_fourcc.h`
> > + */
> > +
> > #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
> > ((__u32)(c) << 16) | ((__u32)(d) << 24))
> >
> > --
> > 2.16.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:50PM +0530, Uma Shankar wrote:
> Implement Plane Gamma feature for BDW and Gen9 platforms.
>
> v2: Used newly added drm_color_lut_ext structure for enhanced
> precision for Gamma LUT entries.
>
> v3: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c | 5 +++-
> drivers/gpu/drm/i915/i915_reg.h | 25
> drivers/gpu/drm/i915/intel_color.c | 58
>
> drivers/gpu/drm/i915/intel_display.c | 4 +++
> drivers/gpu/drm/i915/intel_sprite.c | 4 +++
> 5 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e931b48..40de78c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -54,7 +54,10 @@
> .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
> IVB_CURSOR_C_OFFSET }
>
> #define BDW_COLORS \
> - .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
> + .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
> + .plane_color = { .plane_degamma_lut_size = 0, \
> + .plane_gamma_lut_size = 16 }
> +
> #define CHV_COLORS \
> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> #define GLK_COLORS \
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0c9f03d..2db6a84 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -172,6 +172,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>
> +/* Plane Gamma Registers */
> +#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
> +#define _MMIO_PLANE_GAMC16(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) *
> 4)
> +
> #define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
> #define _MASKED_FIELD(mask, value) ({
>\
> if (__builtin_constant_p(mask))\
> @@ -9713,6 +9717,27 @@ enum skl_power_gate {
> #define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
> _PRE_CSC_GAMC_INDEX_B)
> #define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
> _PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
>
> +/* Plane Gamma in Gen9+ */
> +#define _PLANE_GAMC_1_A 0x701d0
> +#define _PLANE_GAMC_1_B 0x711d0
> +#define _PLANE_GAMC_2_A 0x702d0
> +#define _PLANE_GAMC_2_B 0x712d0
> +#define _PLANE_GAMC_1(pipe) _PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
> +#define _PLANE_GAMC_2(pipe) _PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
> +#define PLANE_GAMC(pipe, plane, i) \
> + _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
> +
> +#define _PLANE_GAMC16_1_A0x70210
> +#define _PLANE_GAMC16_1_B0x71210
> +#define _PLANE_GAMC16_2_A0x70310
> +#define _PLANE_GAMC16_2_B0x71310
> +#define _PLANE_GAMC16_1(pipe)_PIPE(pipe, _PLANE_GAMC16_1_A, \
> + _PLANE_GAMC16_1_B)
> +#define _PLANE_GAMC16_2(pipe)_PIPE(pipe, _PLANE_GAMC16_2_A, \
> + _PLANE_GAMC16_2_B)
> +#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
> + _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
> +
> /* pipe CSC & degamma/gamma LUTs on CHV */
> #define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
> #define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index fb8402f..2b5c0cd 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -492,6 +492,59 @@ static void broadwell_load_luts(struct drm_crtc_state
> *state)
> I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> }
>
> +static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
> + u32 offset)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
> + enum pipe pipe = to_intel_plane(state->plane)->pipe;
> + enum plane_id plane = to_intel_plane(state->plane)->id;
> + uint32_t i, lut_size =
> + INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
> +
> + if (state->gamma_lut) {
> + struct drm_color_lut_ext *lut =
> + (struct drm_color_lut_ext *) state->gamma_lut->data;
> +
> + for (i = 0; i < lut_size; i++) {
> + uint32_t word =
> + (drm_color_lut_extract(lut[i].red, 10) << 20) |
> + (drm_color_lut_extract(lut[i].green, 10) << 10) |
> + drm_color_lut_extract(lut[i].blue, 10);
Shouldn't you be using drm_color_lut_extract_ext ?
> +
> + I915_WRITE(P
Re: [RFC v4 5/8] drm: Define helper function for plane color enabling
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:48PM +0530, Uma Shankar wrote:
> Define helper function to enable Plane color features
> to attach plane color properties to plane structure.
>
> v2: Rebase
>
> v3: Modiefied the function to use updated property names.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_plane.c | 42 ++
> include/drm/drm_color_mgmt.h | 5 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index d0bf10b..d1b4ac1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev,
> struct drm_plane *plane
> }
>
> /**
> + * drm_plane_enable_color_mgmt - enable color management properties
> + * @plane: DRM Plane
> + * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
> + * @plane_has_ctm: whether to attach ctm_property for CSC matrix
> + * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
> + *
> + * This function lets the driver enable the color correction
> + * properties on a plane. This includes 3 degamma, csc and gamma
> + * properties that userspace can set and 2 size properties to inform
> + * the userspace of the lut sizes. Each of the properties are
> + * optional. The gamma and degamma properties are only attached if
> + * their size is not 0 and ctm_property is only attached if has_ctm is
> + * true.
> + */
> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
> + uint plane_degamma_lut_size,
> + bool plane_has_ctm,
> + uint plane_gamma_lut_size)
> +{
> + if (plane_degamma_lut_size) {
> + drm_object_attach_property(&plane->base,
> + plane->degamma_lut_property, 0);
> + drm_object_attach_property(&plane->base,
> + plane->degamma_lut_size_property,
> + plane_degamma_lut_size);
> + }
> +
> + if (plane_has_ctm)
> + drm_object_attach_property(&plane->base,
> + plane->ctm_property, 0);
> +
> + if (plane_gamma_lut_size) {
> + drm_object_attach_property(&plane->base,
> + plane->gamma_lut_property, 0);
> + drm_object_attach_property(&plane->base,
> + plane->gamma_lut_size_property,
> + plane_gamma_lut_size);
> + }
> +}
> +EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
> +
> +/**
> * drm_universal_plane_init - Initialize a new universal plane object
> * @dev: DRM device
> * @plane: plane object to init
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 44f04233..9b8e566 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -68,4 +68,9 @@ int drm_plane_create_color_properties(struct drm_plane
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +void drm_plane_enable_color_mgmt(struct drm_plane *plane,
> + uint plane_degamma_lut_size,
> + bool plane_has_ctm,
> + uint plane_gamma_lut_size);
> #endif
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Alexandru Gheorghe
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4 4/8] drm: Add Plane Gamma properties
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:47PM +0530, Uma Shankar wrote:
> Add plane gamma as blob property and size as a
> range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_atomic.c| 9 +
> drivers/gpu/drm/drm_atomic_helper.c | 3 +++
> drivers/gpu/drm/drm_plane.c | 23 +++
> include/drm/drm_plane.h | 22 ++
> 5 files changed, 63 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 16d6d8d..bcf9a86 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -563,6 +563,12 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: ctm_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: gamma_lut_property
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: gamma_lut_size_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ddda935..8b0bf14 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -925,6 +925,13 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == plane->gamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->gamma_lut,
> + val, -1, sizeof(struct drm_color_lut),
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -998,6 +1005,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->degamma_lut->base.id : 0;
> } else if (property == plane->ctm_property) {
> *val = (state->ctm) ? state->ctm->base.id : 0;
> + } else if (property == plane->gamma_lut_property) {
> + *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 866181f..f524255 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3618,6 +3618,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
> drm_property_blob_get(state->degamma_lut);
> if (state->ctm)
> drm_property_blob_get(state->ctm);
> + if (state->gamma_lut)
> + drm_property_blob_put(state->gamma_lut);
>
> state->color_mgmt_changed = false;
> }
> @@ -3667,6 +3669,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
>
> drm_property_blob_put(state->degamma_lut);
> drm_property_blob_put(state->ctm);
> + drm_property_blob_put(state->gamma_lut);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 97520b1..d0bf10b 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -494,6 +494,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
> * Blob property which allows a userspace to provide CTM coefficients
> * to do color space conversion or any other enhancement by doing a
> * matrix multiplication using the h/w CTM processing engine
> + *
> + * gamma_lut_property:
> + * Blob property which allows a userspace to provide LUT values
> + * to apply gamma/tone-mapping curve using the h/w plane gamma
> + * processing engine, thereby making the content as non-linear
> + * or to perform any tone mapping operation for HDR usecases.
> + *
> + * gamma_lut_size_property:
> + * Range Property to indicate size of the plane gamma LUT.
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
> struct drm_plane *plane)
> @@ -521,6 +530,20 @@ int drm_plane_color_create_prop(struct drm_device *dev,
> return -ENOMEM;
> plane->ctm_property = prop;
>
> + prop = drm_property_create(dev,
> +
Re: [RFC v4 3/8] drm: Add Plane CTM property
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:46PM +0530, Uma Shankar wrote:
> Add a blob property for plane CSC usage.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 3 +++
> drivers/gpu/drm/drm_atomic.c| 10 ++
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_plane.c | 12
> include/drm/drm_plane.h | 15 +++
> 5 files changed, 44 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 8b10b12..16d6d8d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -560,6 +560,9 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: degamma_lut_size_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: ctm_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f8cad9b..ddda935 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == plane->ctm_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->ctm,
> + val,
> + sizeof(struct drm_color_ctm), -1,
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> } else if (property == plane->degamma_lut_property) {
> *val = (state->degamma_lut) ?
> state->degamma_lut->base.id : 0;
> + } else if (property == plane->ctm_property) {
> + *val = (state->ctm) ? state->ctm->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 67c5b51..866181f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3616,6 +3616,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
>
> if (state->degamma_lut)
> drm_property_blob_get(state->degamma_lut);
> + if (state->ctm)
> + drm_property_blob_get(state->ctm);
> +
> state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> @@ -3663,6 +3666,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
> drm_crtc_commit_put(state->commit);
>
> drm_property_blob_put(state->degamma_lut);
> + drm_property_blob_put(state->ctm);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 03e0560..97520b1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
> *
> * degamma_lut_size_property:
> * Range Property to indicate size of the plane degamma LUT.
> + *
> + * ctm_property:
> + * Blob property which allows a userspace to provide CTM coefficients
> + * to do color space conversion or any other enhancement by doing a
> + * matrix multiplication using the h/w CTM processing engine
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
> struct drm_plane *plane)
> @@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct drm_device *dev,
> return -ENOMEM;
> plane->degamma_lut_size_property = prop;
>
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB,
> + "PLANE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + plane->ctm_property = prop;
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_color_create_prop);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 28357ac..5143277 100644
> --- a/include/drm/drm_plane.h
> +++ b/in
Re: [RFC v4 2/8] drm: Add Plane Degamma properties
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:45PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 9 +
> drivers/gpu/drm/drm_atomic.c| 13 +
> drivers/gpu/drm/drm_atomic_helper.c | 6 ++
> drivers/gpu/drm/drm_plane.c | 35 +++
> include/drm/drm_plane.h | 24
> 5 files changed, 87 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 5dee6b8..8b10b12 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -551,6 +551,15 @@ Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :export:
>
> +Plane Color Management Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: degamma_lut_property
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: degamma_lut_size_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e..f8cad9b 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -857,6 +857,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> {
> struct drm_device *dev = plane->dev;
> struct drm_mode_config *config = &dev->mode_config;
> + bool replaced = false;
> + int ret;
>
> if (property == config->prop_fb_id) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> val);
> @@ -908,6 +910,13 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> state->color_range = val;
> + } else if (property == plane->degamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->degamma_lut,
> + val, -1, sizeof(struct drm_color_lut),
> + &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -976,6 +985,9 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> *val = state->color_range;
> + } else if (property == plane->degamma_lut_property) {
> + *val = (state->degamma_lut) ?
> + state->degamma_lut->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> @@ -1116,6 +1128,7 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
> drm_get_color_encoding_name(state->color_encoding));
> drm_printf(p, "\tcolor-range=%s\n",
> drm_get_color_range_name(state->color_range));
> + drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
>
> if (plane->funcs->atomic_print_state)
> plane->funcs->atomic_print_state(p, state);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 38ce9a3..67c5b51 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3613,6 +3613,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> drm_plane *plane,
>
> state->fence = NULL;
> state->commit = NULL;
> +
> + if (state->degamma_lut)
> + drm_property_blob_get(state->degamma_lut);
> + state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>
> @@ -3657,6 +3661,8 @@ void __drm_atomic_helper_plane_destroy_state(struct
> drm_plane_state *state)
>
> if (state->commit)
> drm_crtc_commit_put(state->commit);
> +
> + drm_property_blob_put(state->degamma_lut);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index cd71fd0..03e0560 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -478,6 +478,41 @@ int drm_mode_plane_set_obj_prop(s
Re: [RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
Hi Uma,
On Fri, Aug 17, 2018 at 07:48:44PM +0530, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values. Also added the code,
> for extracting the same from values passed from userspace.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_plane.c | 19 +++
> include/uapi/drm/drm_mode.h | 15 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 6153cbd..cd71fd0 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -430,6 +430,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
> }
> EXPORT_SYMBOL(drm_plane_force_disable);
>
> +/*
> + * Added to accommodate enhanced LUT precision.
> + * Max LUT precision is 32 bits.
> + */
> +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t
> bit_precision)
You should declare this function in a header file as well.
With that fixed
Reviewed-by: Alexandru Gheorghe
> +{
> + uint32_t val = user_input;
> + uint32_t max = 0x >> (32 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 32) {
> + val += 1UL << (32 - bit_precision - 1);
> + val >>= 32 - bit_precision;
> + }
> +
> + return clamp_val(val, 0, max);
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
> +
> /**
> * drm_mode_plane_set_obj_prop - set the value of a property
> * @plane: drm plane object to set property value for
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8d67243..874407b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -629,6 +629,21 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/*
> + * Creating 32 bit palette entries for better data
> + * precision. This will be required for HDR and
> + * similar color processing usecases.
> + */
> +struct drm_color_lut_ext {
> + /*
> + * Data is U0.32 fixed point format.
> + */
> + __u32 red;
> + __u32 green;
> + __u32 blue;
> + __u32 reserved;
> +};
> +
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
Hi,
On Tue, Aug 21, 2018 at 10:54:52AM +0200, Daniel Vetter wrote:
> On Mon, Aug 20, 2018 at 10:10:52AM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Tue, Aug 14, 2018 at 10:36:58AM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 10, 2018 at 06:50:31PM +0100, Alexandru Gheorghe wrote:
> > > > DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> > > > to me, so try to clarify that with a bit of ascii graphics.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > include/uapi/drm/drm_mode.h | 11 ++-
> > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > > index 8d67243952f4..ac5de85c93eb 100644
> > > > --- a/include/uapi/drm/drm_mode.h
> > > > +++ b/include/uapi/drm/drm_mode.h
> > > > @@ -186,9 +186,18 @@ extern "C" {
> > > > /*
> > > > * DRM_MODE_REFLECT_
> > > > *
> > > > - * Signals that the contents of a drm plane is reflected in the
> > > > axis,
> > > > + * Signals that the contents of a drm plane is reflected along the
> > > > axis,
> > > > * in the same way as mirroring.
> > > > *
> > > > + * DRM_MODE_REFLECT_X
> > > > + * |o || o|
> > > > + * | | -> | |
> > > > + * | v||v |
> > > > + *
> > > > + * DRM_MODE_REFLECT_Y
> > > > + * |o || ^|
> > > > + * | | -> | |
> > > > + * | v||o |
> > >
> > > I think the above won't render correctly in sphinx. I think you need some
> > > fixed-block quoting. Please run
> > >
> > > $ make htmldocs
> > >
> > > and check the output. With that addressed:
> >
> > One small problem here this file is not included in the htmldoc
> > generation and no comment in here is marked to be included in html
> > documentation.
>
> Hah, I guess my review was sub-par. And with that I realized we have have
> this prop fairly well documented already, but it's hidden in
> drm_plane_create_rotation_property(). Plus linked from
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
>
> Might be better to move everything there, and just leave a hint here?
I agree, it makes perfectly sense to move it to
drm_plane_create_rotation_property and just point to that here.
I will do that in v2.
> -Daniel
>
> >
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > > * This define is provided as a convenience, looking up the property id
> > > > * using the name->prop id lookup is the preferred method.
> > > > */
> > > > --
> > > > 2.18.0
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Cheers,
> > Alex G
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Clarify DRM_MODE_REFLECT_X/Y documentation
On Tue, Aug 14, 2018 at 10:36:58AM +0200, Daniel Vetter wrote:
> On Fri, Aug 10, 2018 at 06:50:31PM +0100, Alexandru Gheorghe wrote:
> > DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> > to me, so try to clarify that with a bit of ascii graphics.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > include/uapi/drm/drm_mode.h | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 8d67243952f4..ac5de85c93eb 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -186,9 +186,18 @@ extern "C" {
> > /*
> > * DRM_MODE_REFLECT_
> > *
> > - * Signals that the contents of a drm plane is reflected in the
> > axis,
> > + * Signals that the contents of a drm plane is reflected along the
> > axis,
> > * in the same way as mirroring.
> > *
> > + * DRM_MODE_REFLECT_X
> > + * |o || o|
> > + * | | -> | |
> > + * | v||v |
> > + *
> > + * DRM_MODE_REFLECT_Y
> > + * |o || ^|
> > + * | | -> | |
> > + * | v||o |
>
> I think the above won't render correctly in sphinx. I think you need some
> fixed-block quoting. Please run
>
> $ make htmldocs
>
> and check the output. With that addressed:
One small problem here this file is not included in the htmldoc
generation and no comment in here is marked to be included in html
documentation.
>
> Reviewed-by: Daniel Vetter
>
> > * This define is provided as a convenience, looking up the property id
> > * using the name->prop id lookup is the preferred method.
> > */
> > --
> > 2.18.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: Make drm_gem_fb_alloc available for drivers to use
On Wed, Aug 15, 2018 at 01:54:12PM +0200, Daniel Vetter wrote: > On Wed, Aug 15, 2018 at 12:08:38PM +0100, Liviu Dudau wrote: > > On Thu, Jul 26, 2018 at 03:10:04PM +0100, Alexandru Gheorghe wrote: > > > Some drivers can't use drm_gem_fb_create, so instead of copying the > > > logic that does the framebuffer allocation allow them to use core > > > drm_gem_fb_alloc. > > > > > > Signed-off-by: Alexandru Gheorghe > > > > To me it looks like an useful thing to have exported, so for what is worth: > > > > Acked-by: Liviu Dudau > > > > Sean, Maarten, Laurent, Gustavo, Daniel(s), do you have any objections? > > In general please add meaningful kernel-doc for exported functions, > explaing what's different and how it works together. > > Wrt the specific issue, I think we should teach drm core and helpers how > to allocate formats with tiled blocks. Means we need to extend > drm_format_info a bit. Your YUV formats won't be the only ones where the > format itself arranges pixels in blocks, and hence has format-based > alignment criteria for pitch and size (due to line rounding). Something like a tile_size or do you have other ideas ? Any idea if there are any tile formats out there where the tile it's not a square ? > > I think this would also fit better into the overall design where drivers > can overwrite the drm_format_info for specific (fourcc, modifier) > combinations. > -Daniel > > > > > > Best regards, > > Liviu > > > > > --- > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 ++- > > > include/drm/drm_gem_framebuffer_helper.h | 5 + > > > 2 files changed, 7 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c > > > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c > > > index 2810d4131411..64eddf5a1bd9 100644 > > > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c > > > +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c > > > @@ -57,7 +57,7 @@ struct drm_gem_object *drm_gem_fb_get_obj(struct > > > drm_framebuffer *fb, > > > } > > > EXPORT_SYMBOL_GPL(drm_gem_fb_get_obj); > > > > > > -static struct drm_framebuffer * > > > +struct drm_framebuffer * > > > drm_gem_fb_alloc(struct drm_device *dev, > > >const struct drm_mode_fb_cmd2 *mode_cmd, > > >struct drm_gem_object **obj, unsigned int num_planes, > > > @@ -85,6 +85,7 @@ drm_gem_fb_alloc(struct drm_device *dev, > > > > > > return fb; > > > } > > > +EXPORT_SYMBOL_GPL(drm_gem_fb_alloc); > > > > > > /** > > > * drm_gem_fb_destroy - Free GEM backed framebuffer > > > diff --git a/include/drm/drm_gem_framebuffer_helper.h > > > b/include/drm/drm_gem_framebuffer_helper.h > > > index a38de7eb55b4..d20c1356000a 100644 > > > --- a/include/drm/drm_gem_framebuffer_helper.h > > > +++ b/include/drm/drm_gem_framebuffer_helper.h > > > @@ -14,6 +14,11 @@ struct drm_simple_display_pipe; > > > > > > struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb, > > > unsigned int plane); > > > +struct drm_framebuffer * > > > +drm_gem_fb_alloc(struct drm_device *dev, > > > + const struct drm_mode_fb_cmd2 *mode_cmd, > > > + struct drm_gem_object **obj, unsigned int num_planes, > > > + const struct drm_framebuffer_funcs *funcs); > > > void drm_gem_fb_destroy(struct drm_framebuffer *fb); > > > int drm_gem_fb_create_handle(struct drm_framebuffer *fb, struct drm_file > > > *file, > > >unsigned int *handle); > > > -- > > > 2.18.0 > > > > > > > -- > > > > | I would like to | > > | fix the world, | > > | but they're not | > > | giving me the | > > \ source code! / > > --- > > ¯\_(ツ)_/¯ > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm: Introduce new DRM_FORMAT_XYUV
Hi Stanislav,
FYI, we are trying to add same format under a slightly different name.
See https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html
On Fri, Aug 10, 2018 at 04:19:03PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> v5: This is YUV444 packed format same as AYUV, but without alpha,
> as supported by i915.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..5bde1b20a098 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_XYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = false
> },
I would rather drop the .has_alpha = false, since these lines are long
enough already.
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index d5e52350a3aa..c4eb69468eda 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -112,6 +112,7 @@ extern "C" {
> #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y') /*
> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>
> #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U', 'V') /*
> [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
>
> /*
> * 2 plane RGB + A
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic
Hi Eric, On Mon, Aug 06, 2018 at 12:58:20PM -0700, Eric Anholt wrote: > Alexandru Gheorghe writes: > > > A new helper function(__drm_atomic_helper_plane_reset) has been added > > for linking a plane with its state and resetting the core > > properties(alpha, rotation, etc.) to their default values. > > Use that instead of duplicating the logic. > > > > __drm_atomic_helper_plane_reset initializes the alpha property to its > > max value, which is defined by the drm core as DRM_BLEND_ALPHA_OPAQUE, > > so nothing changes regarding the alpha value. > > > > Signed-off-by: Alexandru Gheorghe > > Acked-by: Eric Anholt Pushed to drmi-misc-next. -- Cheers, Alex G IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
Hi Sinclair, Is it ok if I merge this patch through drm-misc-next ? Thank you, Alex Gheorghe On Mon, Aug 06, 2018 at 09:57:53AM -0700, Sinclair Yeh wrote: > Acked-by: Sinclair Yeh > > On Sat, Aug 04, 2018 at 05:15:30PM +0100, Alexandru Gheorghe wrote: > > A new helper function(__drm_atomic_helper_plane_reset) has been added > > for linking a plane with its state and resetting the core > > properties(alpha, rotation, etc.) to their default values. > > Use that instead of duplicating the logic. > > > > Reviewed-by: Sinclair Yeh > > Reviewed-by: Deepak Rawat > > Signed-off-by: Alexandru Gheorghe > > --- > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > index 4a0f0f41afa1..61824e360619 100644 > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane) > > return; > > } > > > > - plane->state = &vps->base; > > - plane->state->plane = plane; > > - plane->state->rotation = DRM_MODE_ROTATE_0; > > + __drm_atomic_helper_plane_reset(plane, &vps->base); > > } > > > > > > -- > > 2.18.0 > > -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/10] Add helper for plane reset
On Mon, Aug 06, 2018 at 02:45:42PM +0300, Laurent Pinchart wrote: Hi Laurent, > Hi Alex, > > On Monday, 6 August 2018 14:07:27 EEST Alexandru-Cosmin Gheorghe wrote: > > Hi, > > > > On Sat, Aug 04, 2018 at 05:15:20PM +0100, Alexandru Gheorghe wrote: > > > No significant change since v2, fixed a spelling mistake and > > > added/removed some newlines in 01 and 07 patches. > > > > > > I plan to apply the first patch of the series and the patches for > > > the drivers maintained through drm-misc(that go Reviewed/Ack) in > > > drm-misc-next on Monday. > > > > > > For the other drivers please let me know if you want me to push them > > > in drm-misc-next as well. > > > > Pushed the following patch to drm-misc-next: > > > > drm/atomic: Add __drm_atomic_helper_plane_reset > > drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying the > > logic > > drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of copying the > > logic > > drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic > > drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the logic > > I've acked the rcar-du part, could it be merged with the rest of the code ? > Done, it's in drm-misc-next now. I didn't know how to handle this for drivers that have their own tree, so I just pushed the patches where I was explicitly asked. Thank you, Alex Gheorghe > > > Changes since v1: > > > - Make __drm_atomic_helper_plane_reset consistent with the other > > >helpers and require that both plane and state not be NULL, > > >suggested by Boris Brezillon and Philipp Zabel. Drivers already > > >check for that. > > > > > > - Add a proper commit message for driver changes. > > > > > > Drivers that subclass drm_plane need to copy the logic for linking the > > > drm_plane with its state and to initialize core properties to their > > > default values. E.g (alpha and rotation) > > > > > > Having a helper to reset the plane_state makes sense because of multiple > > > reasons: > > > 1. Eliminate code duplication. > > > 2. Add a single place for initializing core properties to their > > > default values, no need for driver to do it if what the helper sets > > > makes sense for them. > > > 3. No need to debug the driver when you enable a core property and > > > observe it doesn't have a proper default value. > > > > > > Tested with mali-dp the other drivers are just built-tested. > > > > > > Alexandru Gheorghe (10): > > > drm/atomic: Add __drm_atomic_helper_plane_reset > > > drm/amd/display: Use __drm_atomic_helper_plane_reset instead of > > > copying the logic > > > drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying > > > the logic > > > drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of > > > copying the logic > > > drm/exynos: Use __drm_atomic_helper_plane_reset instead of copying the > > > logic > > > drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the > > > logic > > > drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying > > > the logic > > > drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the > > > logic > > > drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the > > > logic > > > drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the > > > logic > > > > > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-- > > > drivers/gpu/drm/arm/malidp_planes.c | 7 ++-- > > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +-- > > > drivers/gpu/drm/drm_atomic_helper.c | 33 ++- > > > drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 +- > > > drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++--- > > > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++-- > > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 +-- > > > drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-- > > > drivers/gpu/drm/vc4/vc4_plane.c | 4 +-- > > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-- > > > include/drm/drm_atomic_helper.h | 2 ++ > > > 12 files changed, 41 insertions(+), 47 deletions(-) > > -- > Regards, > > Laurent Pinchart > > -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/10] Add helper for plane reset
Hi, On Sat, Aug 04, 2018 at 05:15:20PM +0100, Alexandru Gheorghe wrote: > No significant change since v2, fixed a spelling mistake and > added/removed some newlines in 01 and 07 patches. > > I plan to apply the first patch of the series and the patches for > the drivers maintained through drm-misc(that go Reviewed/Ack) in > drm-misc-next on Monday. > > For the other drivers please let me know if you want me to push them > in drm-misc-next as well. Pushed the following patch to drm-misc-next: drm/atomic: Add __drm_atomic_helper_plane_reset drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying the logic drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the logic Thank you, Alex Gheorghe. > > Changes since v1: > - Make __drm_atomic_helper_plane_reset consistent with the other >helpers and require that both plane and state not be NULL, >suggested by Boris Brezillon and Philipp Zabel. Drivers already >check for that. > - Add a proper commit message for driver changes. > > Drivers that subclass drm_plane need to copy the logic for linking the > drm_plane with its state and to initialize core properties to their > default values. E.g (alpha and rotation) > > Having a helper to reset the plane_state makes sense because of multiple > reasons: > 1. Eliminate code duplication. > 2. Add a single place for initializing core properties to their > default values, no need for driver to do it if what the helper sets > makes sense for them. > 3. No need to debug the driver when you enable a core property and > observe it doesn't have a proper default value. > > Tested with mali-dp the other drivers are just built-tested. > > > Alexandru Gheorghe (10): > drm/atomic: Add __drm_atomic_helper_plane_reset > drm/amd/display: Use __drm_atomic_helper_plane_reset instead of > copying the logic > drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying > the logic > drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of > copying the logic > drm/exynos: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying > the logic > drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the > logic > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-- > drivers/gpu/drm/arm/malidp_planes.c | 7 ++-- > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +-- > drivers/gpu/drm/drm_atomic_helper.c | 33 ++- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 +- > drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++--- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++-- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 +-- > drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-- > drivers/gpu/drm/vc4/vc4_plane.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-- > include/drm/drm_atomic_helper.h | 2 ++ > 12 files changed, 41 insertions(+), 47 deletions(-) > > -- > 2.18.0 -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 06/10] drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic
On Mon, Aug 06, 2018 at 08:29:13AM +0200, Philipp Zabel wrote:
Hi,
> Hi Alexandru,
>
> On Sat, 2018-08-04 at 17:15 +0100, Alexandru Gheorghe wrote:
> > A new helper function(__drm_atomic_helper_plane_reset) has been added
> > for linking a plane with its state and resetting the core
> > properties(alpha, rotation, etc.) to their default values.
> > Use that instead of duplicating the logic.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/imx/ipuv3-plane.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index 203f247d4854..1bd4de03ce9e 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -281,16 +281,14 @@ static void ipu_plane_state_reset(struct drm_plane
> > *plane)
> > ipu_state = to_ipu_plane_state(plane->state);
> > __drm_atomic_helper_plane_destroy_state(plane->state);
> > kfree(ipu_state);
> > + plane->state = NULL;
> > }
> >
> > ipu_state = kzalloc(sizeof(*ipu_state), GFP_KERNEL);
> >
> > - if (ipu_state) {
> > - ipu_state->base.plane = plane;
> > - ipu_state->base.rotation = DRM_MODE_ROTATE_0;
> > - }
> > + if (ipu_state)
> > + __drm_atomic_helper_plane_reset(plane, &ipu_state->base);
> >
>
> Could you remove this white line as well?
Yes, will do before applying.
>
> > - plane->state = &ipu_state->base;
> > }
> >
> > static struct drm_plane_state *
>
> Acked-by: Philipp Zabel
>
> to be merged through drm-misc together with the other changes.
>
> regards
> Philipp
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset
On Tue, Jul 24, 2018 at 10:16:56AM +0200, Boris Brezillon wrote:
> On Tue, 24 Jul 2018 09:14:02 +0100
> Alexandru-Cosmin Gheorghe wrote:
>
> > On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote:
> > > Hi Alexandru,
> > >
> > > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> > > > There are a lot of drivers that subclass drm_plane_state, all of them
> > > > duplicate the code that links toghether the plane with plane_state.
> > > >
> > > > On top of that, drivers that enable core properties also have to
> > > > duplicate the code for initializing the properties to their default
> > > > values, which in all cases are the same as the defaults from core.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_helper.c | 32 +
> > > > include/drm/drm_atomic_helper.h | 2 ++
> > > > 2 files changed, 25 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 8008a7de2e10..e1c6f101652e 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -3507,6 +3507,28 @@ void drm_atomic_helper_crtc_destroy_state(struct
> > > > drm_crtc *crtc,
> > > > }
> > > > EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
> > > >
> > > > +/**
> > > > + * __drm_atomic_helper_plane_reset - resets planes state to default
> > > > values
> > > > + * @plane: plane object
> > > > + * @new_state: atomic plane state
> > > > + *
> > > > + * Initializes plane state to default. This is useful for drivers that
> > > > subclass
> > > > + * the plane state.
> > > > + */
> > > > +void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > > > +struct drm_plane_state *state)
> > > > +{
> > > > + if (state) {
> > > > + state->plane = plane;
> > > > + state->rotation = DRM_MODE_ROTATE_0;
> > > > + /* Reset the alpha value to fully opaque if it matters
> > > > */
> > > > + if (plane->alpha_property)
> > > > + state->alpha = plane->alpha_property->values[1];
> > > > + }
> > >
> > > Is this function supposed to be callable with state == NULL ?
> > >
> > > > + plane->state = state;
> > >
> > > If so, the comment could mention that this sets plane->state to NULL if
> > > state == NULL, and a few of the call sites could be simplified.
> > >
> > > If not, I would remove the conditional if (state) {} part and also
> > > mention this in the comment.
> >
> > Yes, It's intended to be callable with null.
>
> May I ask why? I'd assume drivers that call this function to pass a
> non-NULL plane state. What's the use case for passing a NULL state here?
Drivers check it, drm_atomic_helper_plane_reset doesn't.
Looking at the existing __drm_atomic_helper_plane_* it seems they all
assume state not null, so I think it probably makes more sense to do
that for this function as well.
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset
On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote:
> Hi Alexandru,
>
> On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> > There are a lot of drivers that subclass drm_plane_state, all of them
> > duplicate the code that links toghether the plane with plane_state.
> >
> > On top of that, drivers that enable core properties also have to
> > duplicate the code for initializing the properties to their default
> > values, which in all cases are the same as the defaults from core.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 32 +
> > include/drm/drm_atomic_helper.h | 2 ++
> > 2 files changed, 25 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 8008a7de2e10..e1c6f101652e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3507,6 +3507,28 @@ void drm_atomic_helper_crtc_destroy_state(struct
> > drm_crtc *crtc,
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
> >
> > +/**
> > + * __drm_atomic_helper_plane_reset - resets planes state to default values
> > + * @plane: plane object
> > + * @new_state: atomic plane state
> > + *
> > + * Initializes plane state to default. This is useful for drivers that
> > subclass
> > + * the plane state.
> > + */
> > +void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > +struct drm_plane_state *state)
> > +{
> > + if (state) {
> > + state->plane = plane;
> > + state->rotation = DRM_MODE_ROTATE_0;
> > + /* Reset the alpha value to fully opaque if it matters */
> > + if (plane->alpha_property)
> > + state->alpha = plane->alpha_property->values[1];
> > + }
>
> Is this function supposed to be callable with state == NULL ?
>
> > + plane->state = state;
>
> If so, the comment could mention that this sets plane->state to NULL if
> state == NULL, and a few of the call sites could be simplified.
>
> If not, I would remove the conditional if (state) {} part and also
> mention this in the comment.
Yes, It's intended to be callable with null. I will update the
comment.
>
> regards
> Philipp
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic
Hi Maxime, On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote: > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote: > > Signed-off-by: Alexandru Gheorghe > > --- > > drivers/gpu/drm/vc4/vc4_plane.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c > > b/drivers/gpu/drm/vc4/vc4_plane.c > > index 9d7a36f148cf..688ad9bb0f08 100644 > > --- a/drivers/gpu/drm/vc4/vc4_plane.c > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > > @@ -200,9 +200,7 @@ static void vc4_plane_reset(struct drm_plane *plane) > > if (!vc4_state) > > return; > > > > - plane->state = &vc4_state->base; > > - plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE; > > - vc4_state->base.plane = plane; > > + __drm_atomic_helper_plane_reset(plane, &vc4_state->base); > > For vc4, rcar-du, atmel-hlcdc and sun4i, you're changing the reset > value of alpha from DRM_BLEND_ALPHA_OPAQUE to > plane->alpha_property->values[1]. plane->alpha_property->values[1] holds the max value for alpha, and it's initialized by the core to DRM_BLEND_ALPHA_OPAQUE. > > This might or might not be a good idea, but you should definitely > explain why. Would a commit message suffice? Or do you have other ideas? > > Maxime > > -- > Maxime Ripard, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm: mali-dp: Set encoder possible_clones
On Fri, Jul 13, 2018 at 11:47:33AM -0400, Sean Paul wrote:
> On Fri, Jul 13, 2018 at 11:40:13AM -0400, Sean Paul wrote:
> > On Fri, Jul 13, 2018 at 04:11:00PM +0100, Alexandru Gheorghe wrote:
> > > Set possible_clones field to report that the writeback connector and
> > > the one driving the display could be enabled at the same time.
> > >
> >
> > In future, please include a "Changes in vX" section so it's easier to tell
> > what's changed.
Yeah, sorry about that, the patch was so small that it never crossed
my mind.
> >
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > > drivers/gpu/drm/arm/malidp_drv.c | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > index 5b72605..08b5bb2 100644
> > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > @@ -616,6 +616,7 @@ static int malidp_bind(struct device *dev)
> > > struct malidp_hw_device *hwdev;
> > > struct platform_device *pdev = to_platform_device(dev);
> > > struct of_device_id const *dev_id;
> > > + struct drm_encoder *encoder;
> > > /* number of lines for the R, G and B output */
> > > u8 output_width[MAX_OUTPUT_CHANNELS];
> > > int ret = 0, i;
> > > @@ -737,6 +738,15 @@ static int malidp_bind(struct device *dev)
> > > goto bind_fail;
> > > }
> > >
> > > + /* We expect to have a maximum of two encoders one for the actual
>
> Also, while I'm here, drop the comment contents a line. ie:
>
> /*
> * We expect...
> */
>
> Ref:
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting
I blame checkpatch, it should've complain about it.
>
> Sean
>
> > > + * display and a virtual one for the writeback connector
> > > + */
> > > + WARN_ON(drm->mode_config.num_encoder > 2);
> > > + list_for_each_entry(encoder, &drm->mode_config.encoder_list, head) {
> > > + encoder->possible_clones =
> > > + (1 << drm->mode_config.num_encoder) - 1;
> > > + }
> >
> > This loop isn't necessary, you can just do the assignment once instead of
> > num_encoder times :-)
> >
> > Sean
> >
Not sure I get what you are suggesting, there are two encoders, so at least
two assignments and the loop does just that.
> > > +
> > > ret = malidp_irq_init(pdev);
> > > if (ret < 0)
> > > goto irq_init_fail;
> > > --
> > > 2.7.4
> > >
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 0/8] Add Plane Color Properties
Hi Uma, On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote: > > > >-Original Message- > >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of > >Alexandru-Cosmin Gheorghe > >Sent: Monday, June 11, 2018 3:47 PM > >To: Shankar, Uma > >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; > >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville > >; n...@arm.com; Lankhorst, Maarten > > > >Subject: Re: [RFC v3 0/8] Add Plane Color Properties > > > >Hi Uma, > > > >Any progress on userspace for this? > >I was thinking on working on using this in drm_hwcomposer. > > > > Hi Alex, > Not much work has been done till now on user space side. You can go ahead > and try to enable it in drm_hwcomposer. > > Regards, > Uma Shankar > I opened a Merge request in drm_hwcomposer, if you have time please have a look and let me know what you think. [1] https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/25 > >Thank you, > >Alex Gheorghe > > > >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: > >> This patch series adds properties for plane color features. It adds > >> properties for degamma used to linearize data, CSC used for gamut > >> conversion, and gamma used to again non-linearize data as per panel > >> supported color space. These can be utilize by user space to convert > >> planes from one format to another, one color space to another etc. > >> > >> Usersapce can take smart blending decisions and utilize these hardware > >> supported plane color features to get accurate color profile. The same > >> can help in consistent color quality from source to panel taking > >> advantage of advanced color features in hardware. > >> > >> These patches just add the property interfaces and enable helper > >> functions. > >> > >> This series adds Intel Gen9 specific plane gamma feature. We can build > >> up and add other platform/hardware specific implementation on top of > >> this series > >> > >> Note: This is just to get a design feedback whether these interfaces > >> look ok. Based on community feedback on interfaces, we will implement > >> IGT tests to validate plane color features. This is un-tested currently. > >> Also, userspace implementation to use these properties is currently > >> not available. > >> > >> v2: Dropped legacy gamma table for plane as suggested by Maarten. > >> Added Gen9/BDW plane gamma feature and rebase on tot. > >> > >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit > >> precision entries, pointed to by Brian, Starkey for HDR usecases. > >> Addressed Sean,Paul comments and moved plane color properties to > >> drm_plane instead of mode_config. Added property documentation as > >suggested by Daniel, Vetter. > >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > >> > >> Uma Shankar (8): > >> drm: Add Enhanced Gamma LUT precision structure > >> drm: Add Plane Degamma properties > >> drm: Add Plane CTM property > >> drm: Add Plane Gamma properties > >> drm: Define helper function for plane color enabling > >> drm/i915: Enable plane color features > >> drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms > >> drm/i915: Load plane color luts from atomic flip > >> > >> Documentation/gpu/drm-kms.rst | 18 > >> drivers/gpu/drm/drm_atomic.c | 30 +++ > >> drivers/gpu/drm/drm_atomic_helper.c | 12 +++ > >> drivers/gpu/drm/drm_plane.c | 131 > >++ > >> drivers/gpu/drm/i915/i915_drv.h | 5 ++ > >> drivers/gpu/drm/i915/i915_pci.c | 5 +- > >> drivers/gpu/drm/i915/i915_reg.h | 24 ++ > >> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + > >> drivers/gpu/drm/i915/intel_color.c| 80 ++ > >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ > >> drivers/gpu/drm/i915/intel_display.c | 4 + > >> drivers/gpu/drm/i915/intel_drv.h | 10 +++ > >> drivers/gpu/drm/i915/intel_sprite.c | 4 + > >> include/drm/drm_color_mgmt.h | 5 ++ > >> include/drm/drm_plane.h | 66 +++ > >> include/uapi/drm/drm_mode.h | 15 > >> 16 files changed, 417 insertions(+), 1 deletion(-) > >> > >> -- > >> 1.9.1 > >> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >-- > >Cheers, > >Alex G > >___ > >dri-devel mailing list > >dri-devel@lists.freedesktop.org > >https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mali-dp: Set encoder possible_clones
On Thu, Jul 12, 2018 at 03:37:36PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 12, 2018 at 09:48:56AM +0100, Alexandru Gheorghe wrote:
> > Set possible_clones field to report that the writeback connector and
> > the one driving the display could be enabled at the same time.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/arm/malidp_drv.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index 5b72605..3664da9 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -616,6 +616,8 @@ static int malidp_bind(struct device *dev)
> > struct malidp_hw_device *hwdev;
> > struct platform_device *pdev = to_platform_device(dev);
> > struct of_device_id const *dev_id;
> > + struct drm_encoder *encoder;
> > + int num_encoders = 0;
> > /* number of lines for the R, G and B output */
> > u8 output_width[MAX_OUTPUT_CHANNELS];
> > int ret = 0, i;
> > @@ -737,6 +739,14 @@ static int malidp_bind(struct device *dev)
> > goto bind_fail;
> > }
> >
> > + list_for_each_entry(encoder, &drm->mode_config.encoder_list, head) {
> > + num_encoders++;
> > + }
>
> dev->mode_config.num_encoder ?
Thanks for that, I will use it.
>
> > +
> > + list_for_each_entry(encoder, &drm->mode_config.encoder_list, head) {
> > + encoder->possible_clones = (1 << num_encoders) - 1;
> > + }
>
> Your commit message speaks only about two specific encoders but here
> you're claiming any encoder can be cloned with any other. I can't
> actually figure out how many encoders there can be because the encoder
> registration seems to happen by magic means. Some explanation would
> be nice.
>
> I'm interested because I'd like to clean up the possible_clones stuff
> to actually reflect reality so that userspace could actually use that
> information for something. See
> https://patchwork.freedesktop.org/series/44849/
>
There are just two encoders, encoder->possible_clones = 0x3 would've
done the job, do you think I should use it to better convey intent?
> > +
> > ret = malidp_irq_init(pdev);
> > if (ret < 0)
> > goto irq_init_fail;
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe-helper: Fix modes reporting for writeback connector
On Thu, Jul 12, 2018 at 10:55:47AM +0200, Daniel Vetter wrote:
> On Thu, Jul 12, 2018 at 09:48:02AM +0100, Alexandru Gheorghe wrote:
> > Writeback connector is reported as disconnected, currently this causes
> > the setting of the edid property to null and then exit.
> > In order to properly get the modes for writeback we need to add an
> > exception when connector type is DRM_MODE_CONNECTOR_WRITEBACK.
> >
> > Signed-off-by: Alexandru Gheorghe
>
> Why do you even need a mode list for writeback?
It's used by userspace to know how big the writeback buffer could be.
>
> Also, if you're already faking a mode list for the writeback connector,
> why can't you also fake it's connection status?
> -Daniel
AFAIK Reporting it as disconnected was a way of making sure it will be
ignored by userspace that's not aware of writeback connectorsa. Do you
think it's superfluous with DRM_CLIENT_CAP_WRITEBACK_CONNECTORS ?
>
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 52774339..c7bdbe2 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -472,7 +472,8 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> >
> > dev->mode_config.poll_running = drm_kms_helper_poll;
> >
> > - if (connector->status == connector_status_disconnected) {
> > + if (connector->status == connector_status_disconnected &&
> > + connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) {
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> > connector->base.id, connector->name);
> > drm_mode_connector_update_edid_property(connector, NULL);
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Set current atomic state in drm_private_state
On Fri, Jun 15, 2018 at 11:38:44PM +0300, Ville Syrjälä wrote: > On Wed, May 30, 2018 at 11:22:27PM +0300, Ville Syrjälä wrote: > > On Wed, May 30, 2018 at 06:30:52PM +0100, Alexandru Gheorghe wrote: > > > drm_private_state has a back pointer to the drm_atomic_state, > > > however that was not initialized in drm_atomic_get_private_obj_state > > > after duplication, as it is the case for other drm atomic getters > > > > > > Signed-off-by: Alexandru Gheorghe > > > --- > > > drivers/gpu/drm/drm_atomic.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > > > index 7d25c42..249aaf8 100644 > > > --- a/drivers/gpu/drm/drm_atomic.c > > > +++ b/drivers/gpu/drm/drm_atomic.c > > > @@ -1108,6 +1108,7 @@ drm_atomic_get_private_obj_state(struct > > > drm_atomic_state *state, > > > state->private_objs[index].old_state = obj->state; > > > state->private_objs[index].new_state = obj_state; > > > state->private_objs[index].ptr = obj; > > > + obj_state->state = state; > > > > Reviewed-by: Ville Syrjälä > > And finally pushed to frm-misc-next. Almost forgot about this one. > > Thanks for the patch. Thanks for pushing it. > > > > > I guess no one ever used that pointer. Should we add some WARNs > > to drm_atomic_helper_swap_state() to make sure these are correct? > > > > I think in general life might be nicer if we didn't even have these > > pointers at all. As it stands it's pretty easy to accidentally > > use them when you're not supposed to (eg. after swap_state() try > > to use the new_state->state). But there's tons of code that would > > need to be touched to eliminate them so not a very pleasant project. > > > > > > > > state->num_private_objs = num_objs; > > > > > > -- > > > 2.7.4 > > > > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > > Ville Syrjälä > > Intel > > -- > Ville Syrjälä > Intel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 0/8] Add Plane Color Properties
On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote: > > > >-Original Message- > >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of > >Alexandru-Cosmin Gheorghe > >Sent: Monday, June 11, 2018 3:47 PM > >To: Shankar, Uma > >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; > >emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Ville > >; n...@arm.com; Lankhorst, Maarten > > > >Subject: Re: [RFC v3 0/8] Add Plane Color Properties > > > >Hi Uma, > > > >Any progress on userspace for this? > >I was thinking on working on using this in drm_hwcomposer. > > > > Hi Alex, > Not much work has been done till now on user space side. You can go ahead > and try to enable it in drm_hwcomposer. > Hi, I'm missing the hardware/driver that can do all three operations DEGAMMA, CSC, GAMMA for now, any chance you have a setup env with drm_hwcomposer and you would have time to help me with some testing after I would be writing the code ? Thank you, Alex Gheorghe > Regards, > Uma Shankar > > >Thank you, > >Alex Gheorghe > > > >On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: > >> This patch series adds properties for plane color features. It adds > >> properties for degamma used to linearize data, CSC used for gamut > >> conversion, and gamma used to again non-linearize data as per panel > >> supported color space. These can be utilize by user space to convert > >> planes from one format to another, one color space to another etc. > >> > >> Usersapce can take smart blending decisions and utilize these hardware > >> supported plane color features to get accurate color profile. The same > >> can help in consistent color quality from source to panel taking > >> advantage of advanced color features in hardware. > >> > >> These patches just add the property interfaces and enable helper > >> functions. > >> > >> This series adds Intel Gen9 specific plane gamma feature. We can build > >> up and add other platform/hardware specific implementation on top of > >> this series > >> > >> Note: This is just to get a design feedback whether these interfaces > >> look ok. Based on community feedback on interfaces, we will implement > >> IGT tests to validate plane color features. This is un-tested currently. > >> Also, userspace implementation to use these properties is currently > >> not available. > >> > >> v2: Dropped legacy gamma table for plane as suggested by Maarten. > >> Added Gen9/BDW plane gamma feature and rebase on tot. > >> > >> v3: Added a new drm_color_lut_ext structure to accommodate 32 bit > >> precision entries, pointed to by Brian, Starkey for HDR usecases. > >> Addressed Sean,Paul comments and moved plane color properties to > >> drm_plane instead of mode_config. Added property documentation as > >suggested by Daniel, Vetter. > >> Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > >> > >> Uma Shankar (8): > >> drm: Add Enhanced Gamma LUT precision structure > >> drm: Add Plane Degamma properties > >> drm: Add Plane CTM property > >> drm: Add Plane Gamma properties > >> drm: Define helper function for plane color enabling > >> drm/i915: Enable plane color features > >> drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms > >> drm/i915: Load plane color luts from atomic flip > >> > >> Documentation/gpu/drm-kms.rst | 18 > >> drivers/gpu/drm/drm_atomic.c | 30 +++ > >> drivers/gpu/drm/drm_atomic_helper.c | 12 +++ > >> drivers/gpu/drm/drm_plane.c | 131 > >++ > >> drivers/gpu/drm/i915/i915_drv.h | 5 ++ > >> drivers/gpu/drm/i915/i915_pci.c | 5 +- > >> drivers/gpu/drm/i915/i915_reg.h | 24 ++ > >> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + > >> drivers/gpu/drm/i915/intel_color.c| 80 ++ > >> drivers/gpu/drm/i915/intel_device_info.h | 5 ++ > >> drivers/gpu/drm/i915/intel_display.c | 4 + > >> drivers/gpu/drm/i915/intel_drv.h | 10 +++ > >> drivers/gpu/drm/i915/intel_sprite.c | 4 + > >> include/drm/drm_color_mgmt.h | 5 ++ > >> include/drm/drm_plane.h | 66 +++ > >> include/uapi/drm/drm_mode.h | 15 > >> 16 files changed, 417 insertions(+), 1 deletion(-) > >> > >> -- > >> 1.9.1 > >> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >-- > >Cheers, > >Alex G > >___ > >dri-devel mailing list > >dri-devel@lists.freedesktop.org > >https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 0/8] Add Plane Color Properties
Hi Uma, Any progress on userspace for this? I was thinking on working on using this in drm_hwcomposer. Thank you, Alex Gheorghe On Fri, Mar 09, 2018 at 11:47:41PM +0530, Uma Shankar wrote: > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data, CSC used for gamut > conversion, and gamma used to again non-linearize data as per panel > supported color space. These can be utilize by user space to convert > planes from one format to another, one color space to another etc. > > Usersapce can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches just add the property interfaces and enable helper > functions. > > This series adds Intel Gen9 specific plane gamma feature. We can > build up and add other platform/hardware specific implementation > on top of this series > > Note: This is just to get a design feedback whether these interfaces > look ok. Based on community feedback on interfaces, we will implement > IGT tests to validate plane color features. This is un-tested currently. > Also, userspace implementation to use these properties is currently not > available. > > v2: Dropped legacy gamma table for plane as suggested by Maarten. Added > Gen9/BDW plane gamma feature and rebase on tot. > > v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision > entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul > comments and moved plane color properties to drm_plane instead of > mode_config. Added property documentation as suggested by Daniel, Vetter. > Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > > Uma Shankar (8): > drm: Add Enhanced Gamma LUT precision structure > drm: Add Plane Degamma properties > drm: Add Plane CTM property > drm: Add Plane Gamma properties > drm: Define helper function for plane color enabling > drm/i915: Enable plane color features > drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms > drm/i915: Load plane color luts from atomic flip > > Documentation/gpu/drm-kms.rst | 18 > drivers/gpu/drm/drm_atomic.c | 30 +++ > drivers/gpu/drm/drm_atomic_helper.c | 12 +++ > drivers/gpu/drm/drm_plane.c | 131 > ++ > drivers/gpu/drm/i915/i915_drv.h | 5 ++ > drivers/gpu/drm/i915/i915_pci.c | 5 +- > drivers/gpu/drm/i915/i915_reg.h | 24 ++ > drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + > drivers/gpu/drm/i915/intel_color.c| 80 ++ > drivers/gpu/drm/i915/intel_device_info.h | 5 ++ > drivers/gpu/drm/i915/intel_display.c | 4 + > drivers/gpu/drm/i915/intel_drv.h | 10 +++ > drivers/gpu/drm/i915/intel_sprite.c | 4 + > include/drm/drm_color_mgmt.h | 5 ++ > include/drm/drm_plane.h | 66 +++ > include/uapi/drm/drm_mode.h | 15 > 16 files changed, 417 insertions(+), 1 deletion(-) > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
