Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work

2024-02-17 Thread kernel test robot
Hi Uma,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240216]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes 
linus/master v6.8-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-randconfig-161-20240213 
(https://download.01.org/0day-ci/archive/20240218/202402180051.37wkwgmx-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402180051.37wkwgmx-...@intel.com/

smatch warnings:
drivers/gpu/drm/drm_atomic.c:825 drm_atomic_plane_print_state() warn: 
inconsistent indenting

vim +825 drivers/gpu/drm/drm_atomic.c

   799  
   800  static void drm_atomic_plane_print_state(struct drm_printer *p,
   801  const struct drm_plane_state *state)
   802  {
   803  struct drm_plane *plane = state->plane;
   804  struct drm_rect src  = drm_plane_state_src(state);
   805  struct drm_rect dest = drm_plane_state_dest(state);
   806  
   807  drm_printf(p, "plane[%u]: %s\n", plane->base.id, plane->name);
   808  drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
   809  drm_printf(p, "\tfb=%u\n", state->fb ? state->fb->base.id : 0);
   810  if (state->fb)
   811  drm_framebuffer_print_info(p, 2, state->fb);
   812  drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", 
DRM_RECT_ARG());
   813  drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", 
DRM_RECT_FP_ARG());
   814  drm_printf(p, "\trotation=%x\n", state->rotation);
   815  drm_printf(p, "\tnormalized-zpos=%x\n", state->normalized_zpos);
   816  drm_printf(p, "\tcolor-encoding=%s\n",
   817 drm_get_color_encoding_name(state->color_encoding));
   818  drm_printf(p, "\tcolor-range=%s\n",
   819 drm_get_color_range_name(state->color_range));
   820  drm_printf(p, "\tcolor_mgmt_changed=%d\n", 
state->color_mgmt_changed);
   821  #if 0
   822 drm_printf(p, "\tcolor-pipeline=%s\n",
   823drm_get_color_pipeline_name(state->color_pipeline));
   824  #else
 > 825 drm_printf(p, "\tcolor-pipeline=%d\n",
   826state->color_pipeline ? 
state->color_pipeline->base.id : 0);
   827  #endif
   828  
   829  
   830  if (plane->funcs->atomic_print_state)
   831  plane->funcs->atomic_print_state(p, state);
   832  }
   833  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work

2024-02-16 Thread kernel test robot
Hi Uma,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240216]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes 
linus/master v6.8-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-randconfig-121-20240214 
(https://download.01.org/0day-ci/archive/20240216/202402161931.6z8xdviq-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240216/202402161931.6z8xdviq-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402161931.6z8xdviq-...@intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:11: sparse: sparse: symbol 
>> 'vkms_initialize_tf_pipeline' was not declared. Should it be static?
--
   drivers/gpu/drm/vkms/vkms_composer.c: note: in included file:
>> drivers/gpu/drm/vkms/tests/vkms_color_tests.c:29:29: sparse: sparse: symbol 
>> 'test_linear_lut' was not declared. Should it be static?
>> drivers/gpu/drm/vkms/tests/vkms_color_tests.c:87:32: sparse: sparse: symbol 
>> 'test_matrix_3x4_50_desat' was not declared. Should it be static?
>> drivers/gpu/drm/vkms/tests/vkms_color_tests.c:146:32: sparse: sparse: symbol 
>> 'test_matrix_3x4_bt709_enc' was not declared. Should it be static?

vim +/vkms_initialize_tf_pipeline +11 drivers/gpu/drm/vkms/vkms_colorop.c

10  
  > 11  const int vkms_initialize_tf_pipeline(struct drm_plane *plane, struct 
drm_prop_enum_list *list)
12  {
13  
14  struct drm_colorop *op, *prev_op;
15  struct drm_device *dev = plane->dev;
16  int ret;
17  
18  /* 1st op: 1d curve */
19  op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
20  if (!op) {
21  DRM_ERROR("KMS: Failed to allocate colorop\n");
22  return -ENOMEM;
23  }
24  
25  ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_1D_CURVE);
26  if (ret)
27  return ret;
28  
29  list->type = op->base.id;
30  list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", 
op->base.id);
31  
32  prev_op = op;
33  
34  /* 2nd op: 3x4 matrix */
35  op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
36  if (!op) {
37  DRM_ERROR("KMS: Failed to allocate colorop\n");
38  return -ENOMEM;
39  }
40  
41  ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_CTM_3X4);
42  if (ret)
43  return ret;
44  
45  drm_colorop_set_next_property(prev_op, op);
46  
47  prev_op = op;
48  
49  /* 3rd op: 3x4 matrix */
50  op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
51  if (!op) {
52  DRM_ERROR("KMS: Failed to allocate colorop\n");
53  return -ENOMEM;
54  }
55  
56  ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_CTM_3X4);
57  if (ret)
58  return ret;
59  
60  drm_colorop_set_next_property(prev_op, op);
61  
62  prev_op = op;
63  
64  /* 4th op: 1d curve */
65  op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
66  if (!op) {
67  DRM_ERROR("KMS: Failed to allocate colorop\n");
68  return -ENOMEM;
69  }
70  
71  ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_1D_CURVE);
72  if (ret)
73  return ret;
74  
75  drm_colorop_set_next_property(prev_op, op);
76  
77  return 0;
78  }
79  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work

2024-02-13 Thread kernel test robot
Hi Uma,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240213]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes 
linus/master v6.8-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-allyesconfig 
(https://download.01.org/0day-ci/archive/20240214/202402141056.lzcslaot-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240214/202402141056.lzcslaot-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402141056.lzcslaot-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/tests/drm_fixp_test.c:11:59: warning: overflow in 
>> expression; result is 9223372036854775807 with type 'long long' 
>> [-Winteger-overflow]
  11 | KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) - 
1));
 |  ^
   1 warning generated.
--
>> drivers/gpu/drm/vkms/vkms_composer.c:95:5: warning: no previous prototype 
>> for function 'lerp_u16' [-Wmissing-prototypes]
  95 | u16 lerp_u16(u16 a, u16 b, s64 t)
 | ^
   drivers/gpu/drm/vkms/vkms_composer.c:95:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
  95 | u16 lerp_u16(u16 a, u16 b, s64 t)
 | ^
 | static 
>> drivers/gpu/drm/vkms/vkms_composer.c:105:5: warning: no previous prototype 
>> for function 'get_lut_index' [-Wmissing-prototypes]
 105 | s64 get_lut_index(const struct vkms_color_lut *lut, u16 
channel_value)
 | ^
   drivers/gpu/drm/vkms/vkms_composer.c:105:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
 105 | s64 get_lut_index(const struct vkms_color_lut *lut, u16 
channel_value)
 | ^
 | static 
>> drivers/gpu/drm/vkms/vkms_composer.c:167:6: warning: no previous prototype 
>> for function 'apply_3x4_matrix' [-Wmissing-prototypes]
 167 | void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct 
drm_color_ctm_3x4 *matrix)
 |  ^
   drivers/gpu/drm/vkms/vkms_composer.c:167:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
 167 | void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct 
drm_color_ctm_3x4 *matrix)
 | ^
 | static 
   3 warnings generated.
--
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:1: warning: 'const' type qualifier on 
>> return type has no effect [-Wignored-qualifiers]
  11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane, 
struct drm_prop_enum_list *list)
 | ^
>> drivers/gpu/drm/vkms/vkms_colorop.c:11:11: warning: no previous prototype 
>> for function 'vkms_initialize_tf_pipeline' [-Wmissing-prototypes]
  11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane, 
struct drm_prop_enum_list *list)
 |   ^
   drivers/gpu/drm/vkms/vkms_colorop.c:11:7: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
  11 | const int vkms_initialize_tf_pipeline(struct drm_plane *plane, 
struct drm_prop_enum_list *list)
 |   ^
 | static 
>> drivers/gpu/drm/vkms/vkms_colorop.c:80:5: warning: no previous prototype for 
>> function 'vkms_initialize_colorops' [-Wmissing-prototypes]
  80 | int vkms_initialize_colorops(struct drm_plane *plane)
 | ^
   drivers/gpu/drm/vkms/vkms_colorop.c:80:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
  80 | int vkms_initialize_colorops(struct drm_plane *plane)
 | ^
 | static 
   3 warnings generated.


vim +11 drivers/gpu/drm/tests/drm_fixp_test.c

 8  
 9  static void drm_test_sm2fixp(struct kunit *test)
10  {
  > 11  KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) - 1));
12  
13  /* 1 */
14

Re: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work

2024-02-13 Thread kernel test robot
Hi Uma,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next next-20240213]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes 
linus/master v6.8-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Uma-Shankar/drm-color-pipeline-base-work/20240213-144544
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240213064835.139464-2-uma.shankar%40intel.com
patch subject: [PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work
config: x86_64-defconfig 
(https://download.01.org/0day-ci/archive/20240214/202402140432.nufiowye-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240214/202402140432.nufiowye-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402140432.nufiowye-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/drm_colorop.c:268: warning: Function parameter or struct 
>> member 'type' not described in 'drm_get_colorop_curve_1d_type_name'
   drivers/gpu/drm/drm_colorop.c:268: warning: Excess function parameter 
'range' description in 'drm_get_colorop_curve_1d_type_name'


vim +268 drivers/gpu/drm/drm_colorop.c

   259  
   260  /**
   261   * drm_get_colorop_curve_1d_type_name - return a string for 1D curve 
type
   262   * @range: 1d curve type to compute name of
   263   *
   264   * In contrast to the other drm_get_*_name functions this one here 
returns a
   265   * const pointer and hence is threadsafe.
   266   */
   267  const char *drm_get_colorop_curve_1d_type_name(enum 
drm_colorop_curve_1d_type type)
 > 268  {
   269  if (WARN_ON(type >= ARRAY_SIZE(colorop_curve_1d_type_name)))
   270  return "unknown";
   271  
   272  return colorop_curve_1d_type_name[type];
   273  }
   274  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


[PATCH 01/28] [NOT FOR REVIEW] drm: color pipeline base work

2024-02-12 Thread Uma Shankar
From: Harry Wentland 

This is a squashed patch based on a series sent out by Harry wentland.
It contains all the changes in the series(v3) currently under review
below.

https://patchwork.freedesktop.org/patch/566614/?series=123446=3

This patch lays the ground work for incremental changes and Intel
specific pipeline changes.

NOTE: This patch is not meant for review. Any review related to this
patch should be done on the original series. In order not to diverge
the discussion from the main series.

Signed-off-by: Harry Wentland 
Signed-off-by: Chaitanya Kumar Borah 
Signed-off-by: Uma Shankar 
---
 Documentation/gpu/rfc/color_pipeline.rst  | 352 
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_atomic.c  | 147 
 drivers/gpu/drm/drm_atomic_helper.c   |  12 +
 drivers/gpu/drm/drm_atomic_state_helper.c |   5 +
 drivers/gpu/drm/drm_atomic_uapi.c | 161 
 drivers/gpu/drm/drm_colorop.c | 292 +++
 drivers/gpu/drm/drm_ioctl.c   |   7 +
 drivers/gpu/drm/drm_mode_config.c |   7 +
 drivers/gpu/drm/tests/Makefile|   4 +-
 drivers/gpu/drm/tests/drm_fixp_test.c |  69 ++
 drivers/gpu/drm/vkms/Kconfig  |   5 +
 drivers/gpu/drm/vkms/Makefile |   4 +-
 drivers/gpu/drm/vkms/tests/.kunitconfig   |   4 +
 drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 355 
 drivers/gpu/drm/vkms/vkms_colorop.c   | 115 +++
 drivers/gpu/drm/vkms/vkms_composer.c  | 117 ++-
 drivers/gpu/drm/vkms/vkms_drv.h   |   8 +
 drivers/gpu/drm/vkms/vkms_luts.c  | 802 ++
 drivers/gpu/drm/vkms/vkms_luts.h  |  12 +
 drivers/gpu/drm/vkms/vkms_plane.c |   2 +
 include/drm/drm_atomic.h  |  84 ++
 include/drm/drm_atomic_uapi.h |   3 +
 include/drm/drm_colorop.h | 258 ++
 include/drm/drm_file.h|   7 +
 include/drm/drm_fixed.h   |  18 +
 include/drm/drm_mode_config.h |  18 +
 include/drm/drm_plane.h   |  10 +
 include/uapi/drm/drm.h|  18 +
 include/uapi/drm/drm_mode.h   |   6 +
 30 files changed, 2899 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
 create mode 100644 drivers/gpu/drm/drm_colorop.c
 create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c
 create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
 create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
 create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h
 create mode 100644 include/drm/drm_colorop.h

diff --git a/Documentation/gpu/rfc/color_pipeline.rst 
b/Documentation/gpu/rfc/color_pipeline.rst
new file mode 100644
index ..efc70570a592
--- /dev/null
+++ b/Documentation/gpu/rfc/color_pipeline.rst
@@ -0,0 +1,352 @@
+
+Linux Color Pipeline API
+
+
+What problem are we solving?
+
+
+We would like to support pre-, and post-blending complex color
+transformations in display controller hardware in order to allow for
+HW-supported HDR use-cases, as well as to provide support to
+color-managed applications, such as video or image editors.
+
+It is possible to support an HDR output on HW supporting the Colorspace
+and HDR Metadata drm_connector properties, but that requires the
+compositor or application to render and compose the content into one
+final buffer intended for display. Doing so is costly.
+
+Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other
+operations to support color transformations. These operations are often
+implemented in fixed-function HW and therefore much more power efficient than
+performing similar operations via shaders or CPU.
+
+We would like to make use of this HW functionality to support complex color
+transformations with no, or minimal CPU or shader load.
+
+
+How are other OSes solving this problem?
+
+
+The most widely supported use-cases regard HDR content, whether video or
+gaming.
+
+Most OSes will specify the source content format (color gamut, encoding 
transfer
+function, and other metadata, such as max and average light levels) to a 
driver.
+Drivers will then program their fixed-function HW accordingly to map from a
+source content buffer's space to a display's space.
+
+When fixed-function HW is not available the compositor will assemble a shader 
to
+ask the GPU to perform the transformation from the source content format to the
+display's format.
+
+A compositor's mapping function and a driver's mapping function are usually
+entirely separate concepts. On OSes where a HW vendor has no insight into