[PATCH 00/11]: Color manager framework for I915 driver

[PATCH 00/11]: Color manager framework for I915 driver

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patchset adds color-manager, a new framework in I915 driver which
adds color correction and tweak capabilities in the driver.

Color manager creates a DRM propery based interface for each color
correction, and based on the property type, registers it with each
CRTC/plane available. 

The current implementation is for valleyview family.
Valleyview supports following color correction properties:
1. CSC correction (wide gamut): This is a pipe level correction.
There are total 9 correction coefficients in form of a 3x3 matrix,
which are to be programmed on 6 correction registers. CSC correction

2. Gamma correction: This is also pipe level correction
There are total 256 palette registers, which can be programmed with
128 correction values, in 10.6 (10bit) format. The expected color
Correction can be applied using 129, 64 bit correction values.
First 128 correction values are to program palette, 129th value is for 
GCMAX register value.
correction format in a 64 bit value is: 
| <16 higher bits>| <16bit R value>|<16 bit G value>|<16 bit B value>|

3. Contrast: This is sprite plane level correction
Expected correction value is 9 bit value
Driver expects values in this format:
|bits 64:32 | bits 31:9 | 8:0 contrast correction value|

4. Brightness: This is also a sprite level correction
Expected correction value is 8 bit value
Driver expects values in this format:
|bits 64:32 | bits 31:8 | 7:0 9 bit brightness correction value|

5. Hue and saturation: This is also a sprite level correction
Expected correction value is 32 bit value
Driver expects values in this format:
|bits 64:32| bits 31:0 hs correction value|

Patches:
1. First three patches create the basic framework.
2. Next 4 add functions to do color correction per property.
3. Next 2 add interface to set property.
4. last 2 patches plug-in init and exit in modeset sequences.

Shashank Sharma (11):
  drm/i915: Color manager framework for valleyview
  drm/i915: Register pipe level color properties
  drm/i915: Register plane level color properties
  drm/i915: Add color manager CSC correction
  drm/i915: Add color manager gamma correction
  drm/i915: Add contrast and brightness correction
  drm/i915: Add hue and saturation correction
  drm/i915: Add CRTC set property functions
  drm/i915: Add set plane property functions
  drm/i915: Plug-in color manager init
  drm/i915: Plug-in color manager exit

 drivers/gpu/drm/i915/Makefile        |   3 +-
 drivers/gpu/drm/i915/i915_reg.h      |  22 +
 drivers/gpu/drm/i915/intel_clrmgr.c  | 795 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h  | 282 +++++++++++++
 drivers/gpu/drm/i915/intel_display.c |  50 +++
 drivers/gpu/drm/i915/intel_drv.h     |   6 +
 drivers/gpu/drm/i915/intel_sprite.c  |  45 ++
 7 files changed, 1202 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h

-- 
1.9.1

[PATCH 01/11] drm/i915: Color manager framework for valleyview

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Color manager is a framework which adds color correction
and tuning capabilities in I915 driver. This framework creates
DRM properties for each color correction property, and allows
userspace to tune the display appearance.

This is the first patch of the series, what this patch does is:
1. Create 2 new files
	intel_clrmgr.c
	intel_clrmgr.h
2. Add color manager init function, this functions allocates
   memory to save an array of color properties. This is called
   during the CRTC init and Plane init time.
3. Add color manager exit function. This function free's the
   memory allocated by init function, and registered color
   properties.
4. Some data structure definitions, in header.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/Makefile       |  3 +-
 drivers/gpu/drm/i915/intel_clrmgr.c | 79 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h | 83 +++++++++++++++++++++++++++++++++++++
 3 files changed, 164 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 91bd167..7fa9c58 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -45,7 +45,8 @@ i915-y += intel_bios.o \
 	  intel_modes.o \
 	  intel_overlay.o \
 	  intel_sideband.o \
-	  intel_sprite.o
+	  intel_sprite.o \
+	  intel_clrmgr.o
 i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
 i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
 
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
new file mode 100644
index 0000000..09a168d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * ======
+ * Shashank Sharma <shashank.sharma@intel.com>
+ * Uma Shankar <uma.shankar@intel.com>
+ * Shobhit Kumar <shobhit.kumar@intel.com>
+ * Sonika Jindal <sonika.jindal@intel.com>
+ */
+
+#include "i915_drm.h"
+#include "i915_drv.h"
+#include "i915_reg.h"
+#include "intel_clrmgr.h"
+
+struct clrmgr_status *intel_clrmgr_init(struct drm_device *dev)
+{
+	struct clrmgr_status *status;
+
+	/* Todo: extend this framework for other gen devices also */
+	if (!IS_VALLEYVIEW(dev)) {
+		DRM_ERROR("Color manager is supported for VLV for now\n");
+		return NULL;
+	}
+
+	/* Allocate and attach color status tracker */
+	status = kzalloc(sizeof(struct clrmgr_status), GFP_KERNEL);
+	if (!status) {
+		DRM_ERROR("Out of memory, cant init color manager\n");
+		return NULL;
+	}
+	DRM_DEBUG_DRIVER("\n");
+	return status;
+}
+
+void intel_clrmgr_exit(struct drm_device *dev, struct clrmgr_status *status)
+{
+	u32 count = 0;
+	struct clrmgr_regd_prop *cp;
+
+	if (!status)
+		return;
+
+	/* First free the DRM property, then status */
+	while (count < status->no_of_properties) {
+		cp = status->cp[count++];
+
+		/* Destroy DRM property */
+		drm_property_destroy(dev, cp->property);
+
+		/* Release the color property */
+		kfree(status->cp[count]);
+		status->cp[count] = NULL;
+	}
+
+	/* Now free the status itself */
+	kfree(status);
+	DRM_DEBUG_DRIVER("\n");
+}
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
new file mode 100644
index 0000000..6a36c8d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * =====
+ * Shashank Sharma <shashank.sharma@intel.com>
+ * Uma Shankar <uma.shankar@intel.com>
+ * Shobhit Kumar <shobhit.kumar@intel.com>
+ * Sonika Jindal <sonika.jindal@intel.com>
+ */
+
+#ifndef _I915_CLR_MNGR_H_
+#define _I915_CLR_MNGR_H_
+
+#include "drmP.h"
+#include "intel_drv.h"
+#include <linux/errno.h>
+
+/* Framework defs */
+#define CLRMGR_PROP_MAX				10
+
+/*
+* clrmgr_regd_propery structure
+* This structure encapsulates drm_property, and some
+* additional values which are required during the runtime
+* after registration, to set a value.
+*/
+struct clrmgr_regd_prop {
+	bool enabled;
+	struct drm_property *property;
+	/*
+	* A void * is first arg, so that the same function ptr can be used
+	* for both crtc_property and plane_property
+	*/
+	bool (*set_property)(void *,
+		struct clrmgr_regd_prop *prop, u64 *data);
+};
+
+/* Status of color properties on pipe at any time */
+struct clrmgr_status {
+	u32 no_of_properties;
+	struct clrmgr_regd_prop *cp[CLRMGR_PROP_MAX];
+};
+
+
+/*
+* intel_clrmgr_init:
+* Allocate memory to save color correction
+* properties for that CRTC.
+* input: struct drm_device
+*/
+struct clrmgr_status *intel_clrmgr_init(struct drm_device *dev);
+
+/*
+* intel_clrmgr_exit
+* Free allocated memory for color status
+* Should be called from CRTC/Plane .destroy function
+* input:
+* - drm_device *
+* - status : color status on that CRTC/Plane
+*/
+void intel_clrmgr_exit(struct drm_device *dev, struct clrmgr_status *status);
+
+#endif
-- 
1.9.1

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

[PATCH 02/11] drm/i915: Register pipe level color properties

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

In valleyview we have two pipe level color correction
properties:
1. CSC correction (wide gamut)
2. Gamma correction

What this patch does:
1. This patch adds software infrastructure to register pipe level
   color correction properties per CRTC. Adding a new function,
   intel_attach_pipe_color_correction to register the pipe level
   color correction properties with the given CRTC.
2. Adding a pointer in intel_crtc structure to store this property.
3. Adding structure gen6_pipe_color_corrections, which contains different
   pipe level correction values for VLV.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_clrmgr.c | 148 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h |  64 ++++++++++++++++
 drivers/gpu/drm/i915/intel_drv.h    |   3 +
 3 files changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 09a168d..8d02a62 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -33,6 +33,154 @@
 #include "i915_reg.h"
 #include "intel_clrmgr.h"
 
+/*
+  * Gen 6 SOC allows following color correction values:
+  *	- CSC(wide gamut) with 3x3 matrix = 9 csc correction values.
+  *	- Gamma correction with 128 gamma values.
+  */
+struct clrmgr_property gen6_pipe_color_corrections[] = {
+	{
+		.tweak_id = csc,
+		.type = DRM_MODE_PROP_BLOB,
+		.len = VLV_CSC_MATRIX_MAX_VALS,
+		.name = "csc-correction",
+	},
+	{
+		.tweak_id = gamma,
+		.type = DRM_MODE_PROP_BLOB,
+		.len = VLV_10BIT_GAMMA_MAX_VALS,
+		.name = "gamma-correction",
+	},
+};
+
+struct drm_property *intel_clrmgr_register(struct drm_device *dev,
+	struct drm_mode_object *obj, struct clrmgr_property *cp)
+{
+	struct drm_property *property;
+
+	/* Create drm property */
+	switch (cp->type) {
+	case DRM_MODE_PROP_BLOB:
+		property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+			cp->name, cp->len);
+		if (!property) {
+			DRM_ERROR("Failed to create property %s\n", cp->name);
+			goto error;
+		}
+		break;
+
+	case DRM_MODE_PROP_RANGE:
+		property = drm_property_create_range(dev, DRM_MODE_PROP_RANGE,
+			cp->name, cp->min, cp->max);
+		if (!property) {
+			DRM_ERROR("Failed to create property %s\n", cp->name);
+			goto error;
+		}
+		break;
+
+	default:
+		DRM_ERROR("Unsupported type for property %s\n", cp->name);
+		goto error;
+	}
+	/* Attach property to object */
+	drm_object_attach_property(obj, property, 0);
+	DRM_DEBUG_DRIVER("Registered property %s\n", property->name);
+	return property;
+
+error:
+	DRM_ERROR("Failed to create property %s\n", cp->name);
+	return NULL;
+}
+
+bool intel_clrmgr_register_pipe_property(struct intel_crtc *intel_crtc,
+		struct clrmgr_reg_request *features)
+
+{
+	u32 count = 0;
+	struct clrmgr_property *cp;
+	struct clrmgr_regd_prop *regd_property;
+	struct drm_property *property;
+	struct drm_device *dev = intel_crtc->base.dev;
+	struct drm_mode_object *obj = &intel_crtc->base.base;
+	struct clrmgr_status *status = intel_crtc->color_status;
+
+	/* Color manager initialized? */
+	if (!status) {
+		DRM_ERROR("Register request without pipe init ?\n");
+		return false;
+	}
+
+	/* Validate input */
+	if (!features || !features->no_of_properties) {
+		DRM_ERROR("Invalid input to color manager register\n");
+		return false;
+	}
+
+	/* Create drm property */
+	while (count < features->no_of_properties) {
+		cp = &features->cp[count++];
+		property = intel_clrmgr_register(dev, obj, cp);
+		if (!property) {
+			DRM_ERROR("Failed to register property %s\n",
+				property->name);
+			goto error;
+		}
+
+		/* Add the property in global pipe status */
+		regd_property = kzalloc(sizeof(struct clrmgr_regd_prop),
+							GFP_KERNEL);
+		regd_property->property = property;
+		regd_property->enabled = false;
+		regd_property->set_property = cp->set_property;
+		status->cp[status->no_of_properties++] = regd_property;
+	}
+	/* Successfully registered all */
+	DRM_DEBUG_DRIVER("Registered color properties on pipe %c\n",
+		pipe_name(intel_crtc->pipe));
+	return true;
+
+error:
+	if (--count) {
+		DRM_ERROR("Partial register, can only register:\n");
+		while (count--)
+			DRM_ERROR("%s", status->cp[count]->property->name);
+	} else
+		DRM_ERROR("Can not register any property\n");
+	return false;
+}
+
+void
+intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
+{
+	struct clrmgr_reg_request *features;
+
+	/* Color manager initialized? */
+	if (!intel_crtc->color_status) {
+		DRM_ERROR("Color manager not initialized for PIPE %d\n",
+			intel_crtc->pipe);
+		return;
+	}
+
+	features = kzalloc(sizeof(struct clrmgr_reg_request), GFP_KERNEL);
+	if (!features) {
+		DRM_ERROR("No memory for pipe color features\n");
+		return;
+	}
+
+	features->no_of_properties = ARRAY_SIZE(gen6_pipe_color_corrections);
+	memcpy(features->cp, gen6_pipe_color_corrections,
+			features->no_of_properties *
+				sizeof(struct clrmgr_property));
+
+	/* Register pipe level color properties */
+	if (!intel_clrmgr_register_pipe_property(intel_crtc, features))
+		DRM_ERROR("Register pipe color property failed\n");
+	else
+		DRM_DEBUG_DRIVER("Attached colot corrections for pipe %d\n",
+		intel_crtc->pipe);
+	kfree(features);
+}
+
 struct clrmgr_status *intel_clrmgr_init(struct drm_device *dev)
 {
 	struct clrmgr_status *status;
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index 6a36c8d..7cb2798 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -37,6 +37,25 @@
 
 /* Framework defs */
 #define CLRMGR_PROP_MAX				10
+#define CLRMGR_PROP_NAME_MAX				128
+
+/* CSC / Wide gamut */
+#define VLV_CSC_MATRIX_MAX_VALS			9
+
+/* VLV specific gamma correction defines */
+#define VLV_10BIT_GAMMA_MAX_INDEX			128
+#define CLRMGR_GAMMA_GCMAX_VAL				1
+#define VLV_10BIT_GAMMA_MAX_VALS		(VLV_10BIT_GAMMA_MAX_INDEX + \
+						CLRMGR_GAMMA_GCMAX_VAL)
+
+/* Color manager features */
+enum clrmgr_tweaks {
+	csc = 0,
+	gamma,
+	contrast,
+	brightness,
+	hue_saturation,
+};
 
 /*
 * clrmgr_regd_propery structure
@@ -55,12 +74,57 @@ struct clrmgr_regd_prop {
 		struct clrmgr_regd_prop *prop, u64 *data);
 };
 
+/*
+* clrmgr_propery structure
+* This structure encapsulates drm_property with other
+* values required during the property registration time.
+*/
+struct clrmgr_property {
+	enum clrmgr_tweaks tweak_id;
+	u32 type;
+	u32 len;
+	u64 min;
+	u64 max;
+	char name[CLRMGR_PROP_NAME_MAX];
+
+	bool (*set_property)(void *,
+		struct clrmgr_regd_prop *, u64 *);
+};
+
 /* Status of color properties on pipe at any time */
 struct clrmgr_status {
 	u32 no_of_properties;
 	struct clrmgr_regd_prop *cp[CLRMGR_PROP_MAX];
 };
 
+/*
+* Request to register a color property
+* This contains array of properties to be registered
+* and one count for no of properties
+*/
+struct clrmgr_reg_request {
+	u32 no_of_properties;
+	struct clrmgr_property cp[CLRMGR_PROP_MAX];
+};
+
+/*
+* intel_clrmgr_register_pipe_property
+* register set of properties with a CRTC
+* input:
+* - intel_crtc: the CRTC to register properies with
+* - features: set of color correction features to register
+*/
+bool intel_clrmgr_register_pipe_property(struct intel_crtc *intel_crtc,
+		struct clrmgr_reg_request *features);
+
+/*
+* intel_attach_pipe_color_correction:
+* Register color correction properties as DRM CRTC properties
+* input:
+* - intel_crtc : CRTC to attach color correcection with
+*/
+void
+intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc);
 
 /*
 * intel_clrmgr_init:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fada887..698801a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -428,6 +428,9 @@ struct intel_crtc {
 
 	int scanline_offset;
 	struct intel_mmio_flip mmio_flip;
+
+	/* color-correction */
+	struct clrmgr_status *color_status;
 };
 
 struct intel_plane_wm_parameters {
-- 
1.9.1

Re: [PATCH 02/11] drm/i915: Register pipe level color properties

[Matt Roper]

On Wed, Jul 23, 2014 at 11:34:56PM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> In valleyview we have two pipe level color correction
> properties:
> 1. CSC correction (wide gamut)
> 2. Gamma correction
> 
> What this patch does:
> 1. This patch adds software infrastructure to register pipe level
>    color correction properties per CRTC. Adding a new function,
>    intel_attach_pipe_color_correction to register the pipe level
>    color correction properties with the given CRTC.
> 2. Adding a pointer in intel_crtc structure to store this property.
> 3. Adding structure gen6_pipe_color_corrections, which contains different
>    pipe level correction values for VLV.
> 
> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
...snip...
> +struct drm_property *intel_clrmgr_register(struct drm_device *dev,
> +	struct drm_mode_object *obj, struct clrmgr_property *cp)
> +{
> +	struct drm_property *property;
> +
> +	/* Create drm property */
> +	switch (cp->type) {
> +	case DRM_MODE_PROP_BLOB:
> +		property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +			cp->name, cp->len);
> +		if (!property) {
> +			DRM_ERROR("Failed to create property %s\n", cp->name);
> +			goto error;
> +		}
> +		break;
> +
> +	case DRM_MODE_PROP_RANGE:
> +		property = drm_property_create_range(dev, DRM_MODE_PROP_RANGE,
> +			cp->name, cp->min, cp->max);
> +		if (!property) {
> +			DRM_ERROR("Failed to create property %s\n", cp->name);
> +			goto error;
> +		}
> +		break;
> +
> +	default:
> +		DRM_ERROR("Unsupported type for property %s\n", cp->name);
> +		goto error;
> +	}
> +	/* Attach property to object */
> +	drm_object_attach_property(obj, property, 0);
> +	DRM_DEBUG_DRIVER("Registered property %s\n", property->name);
> +	return property;
> +
> +error:
> +	DRM_ERROR("Failed to create property %s\n", cp->name);
> +	return NULL;
> +}

If I'm reading this right, you're creating a unique property for each
DRM object (crtc in this case) that you work with.  I.e., if you have
three pipes, then you wind up creating three CSC and three gamma
properties total.  This isn't really the way properties are meant to be
used...  A property describes a type of data that you want to store on a
per-object basis, but doesn't actually store anything itself.  You can
then attach that single property to multiple objects and all of those
objects will track their own value of the quantity described by the
property.  It's sort of like the difference between classes and objects
in OOP --- a DRM property is sort of like a class (just describes
something you plan to store) and attaching that property to a CRTC (or
plane, or connector) is like instantiating a new object of the class.

You should really only have two properties being created by the driver
here...one for CSC and one for Gamma.  Once you've created a property
once, you'll attach it to all of your CRTC's and they'll all manage
their own values.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH 03/11] drm/i915: Register plane level color properties

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

In valleyview we have three possible sprite plane level
color correction:
    1. Contrast
    2. Brightness

What this patch does:
1. This patch adds software infrastructure to register plane level
   color correction properties per plane. Adding a new function,
   intel_attach_plane_color_correction to register the plane level
   color correction properties.
2. Adding a pointer in intel_plane structure to store this property.
3. Adding structure gen6_plane_color_corrections, which contains different
   plane level correction values for VLV.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_clrmgr.c | 125 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h |   8 +++
 drivers/gpu/drm/i915/intel_drv.h    |   3 +
 3 files changed, 136 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 8d02a62..0aa3734 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -53,6 +53,41 @@ struct clrmgr_property gen6_pipe_color_corrections[] = {
 	},
 };
 
+/*
+* Gen6 plane level properties:
+* - Contrast adjustment for all sprite planes.
+* - Brightness adjustment for all sprite planes.
+* - Hue and Saturation adjustment for all sprite planes.
+*/
+struct clrmgr_property gen6_plane_color_corrections[] = {
+
+	{
+		.tweak_id = contrast,
+		.type = DRM_MODE_PROP_RANGE,
+		.max = CLRMGR_PROP_RANGE_MAX,
+		.min = 0,
+		.len = VLV_CB_MAX_VALS,
+		.name = "contrast",
+	},
+	{
+		.tweak_id = brightness,
+		.type = DRM_MODE_PROP_RANGE,
+		.max = CLRMGR_PROP_RANGE_MAX,
+		.min = 0,
+		.len = VLV_CB_MAX_VALS,
+		.name = "brightness",
+	},
+	{
+		.tweak_id = hue_saturation,
+		.type = DRM_MODE_PROP_RANGE,
+		.max = CLRMGR_PROP_RANGE_MAX,
+		.min = 0,
+		.len = VLV_HS_MAX_VALS,
+		.name = "hue-saturation",
+	}
+};
+
+
 struct drm_property *intel_clrmgr_register(struct drm_device *dev,
 	struct drm_mode_object *obj, struct clrmgr_property *cp)
 {
@@ -92,6 +127,96 @@ error:
 	return NULL;
 }
 
+bool intel_clrmgr_register_plane_property(struct intel_plane *intel_plane,
+		struct clrmgr_reg_request *features)
+{
+	u32 count = 0;
+	struct clrmgr_property *cp;
+	struct clrmgr_regd_prop *regd_property;
+	struct drm_property *property;
+	struct drm_device *dev = intel_plane->base.dev;
+	struct drm_mode_object *obj = &intel_plane->base.base;
+	struct clrmgr_status *status = intel_plane->color_status;
+
+	/* Color manager initialized? */
+	if (!status) {
+		DRM_ERROR("Register request without plane init ?\n");
+		return false;
+	}
+
+	/* Validate input */
+	if (!features || !features->no_of_properties) {
+		DRM_ERROR("Invalid input to register plane property\n");
+		return false;
+	}
+
+	/* Create drm property */
+	while (count < features->no_of_properties) {
+		cp = &features->cp[count++];
+		property = intel_clrmgr_register(dev, obj, cp);
+		if (!property) {
+			DRM_ERROR("Failed to register property %s\n",
+				property->name);
+			goto error;
+		}
+
+		/* Add the property in global pipe status */
+		regd_property = kzalloc(sizeof(struct clrmgr_regd_prop),
+							GFP_KERNEL);
+		regd_property->property = property;
+		regd_property->enabled = false;
+		regd_property->set_property = cp->set_property;
+		status->cp[status->no_of_properties++] = regd_property;
+	}
+
+	/* Successfully registered all */
+	DRM_DEBUG_DRIVER("Registered color properties on plane %d\n",
+		intel_plane->plane);
+	return true;
+
+error:
+	if (--count) {
+		DRM_ERROR("Can only register following properties:\n");
+		while (count--)
+			DRM_ERROR("%s", status->cp[count]->property->name);
+	} else
+		DRM_ERROR("Can not register any property\n");
+	return false;
+}
+
+void
+intel_attach_plane_color_correction(struct intel_plane *intel_plane)
+{
+	struct clrmgr_reg_request *features;
+
+	/* Color manager initialized? */
+	if (!intel_plane->color_status) {
+		DRM_ERROR("Color manager not initialized for plane %d\n",
+			intel_plane->plane);
+		return;
+	}
+
+	DRM_DEBUG_DRIVER("\n");
+	features = kzalloc(sizeof(struct clrmgr_reg_request), GFP_KERNEL);
+	if (!features) {
+		DRM_ERROR("No memory for plane color features\n");
+		return;
+	}
+
+	features->no_of_properties = ARRAY_SIZE(gen6_plane_color_corrections);
+	memcpy(features->cp, gen6_plane_color_corrections,
+				features->no_of_properties *
+					sizeof(struct clrmgr_property));
+
+	/* Register plane level color properties */
+	if (!intel_clrmgr_register_plane_property(intel_plane, features))
+		DRM_ERROR("Register plane color property failed\n");
+	else
+		DRM_DEBUG_DRIVER("Attached colot corrections for plane %d\n",
+			intel_plane->plane);
+	kfree(features);
+}
+
 bool intel_clrmgr_register_pipe_property(struct intel_crtc *intel_crtc,
 		struct clrmgr_reg_request *features)
 
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index 7cb2798..28fea24 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -38,6 +38,8 @@
 /* Framework defs */
 #define CLRMGR_PROP_MAX				10
 #define CLRMGR_PROP_NAME_MAX				128
+#define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
+
 
 /* CSC / Wide gamut */
 #define VLV_CSC_MATRIX_MAX_VALS			9
@@ -48,6 +50,12 @@
 #define VLV_10BIT_GAMMA_MAX_VALS		(VLV_10BIT_GAMMA_MAX_INDEX + \
 						CLRMGR_GAMMA_GCMAX_VAL)
 
+/* Sprite Contrast and Brightness Registers */
+#define VLV_CB_MAX_VALS				1
+
+/* Sprite Hue and Saturation Registers */
+#define VLV_HS_MAX_VALS				1
+
 /* Color manager features */
 enum clrmgr_tweaks {
 	csc = 0,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 698801a..ed35cdf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -474,6 +474,9 @@ struct intel_plane {
 			       struct drm_intel_sprite_colorkey *key);
 	void (*get_colorkey)(struct drm_plane *plane,
 			     struct drm_intel_sprite_colorkey *key);
+
+	/* color-correction */
+	struct clrmgr_status *color_status;
 };
 
 struct intel_watermark_params {
-- 
1.9.1

[PATCH 04/11] drm/i915: Add color manager CSC correction

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patch adds support for pipe CSC correction color property
for intel color manager framework. It adds two functions:
1. intel_clrmgr_set_csc: This is a wrapper function
   which checks the platform type, and calls the valleyview
   specific set_csc function. As different platforms have different
   methods of setting CSC, this function is required.The support for
   other platfroms can be plugged-in here in the wrapper function.
   Adding this function as .set_property CSC color property.
2. vlv_set_csc: core function to program CSC coefficients as per
   vlv specs, and then enable CSC.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h     | 11 +++++
 drivers/gpu/drm/i915/intel_clrmgr.c | 82 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h | 16 ++++++++
 3 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe5c276..3199f96 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6084,6 +6084,17 @@ enum punit_power_well {
 #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
 #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
 
+/* VLV color correction registers */
+/* CSC */
+#define PIPECONF_CSC_ENABLE	(1 << 15)
+#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
+								0x600b0)
+#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
+								0x610b0)
+#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
+#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
+#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
+
 /* VLV MIPI registers */
 
 #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 0aa3734..601076b 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -44,6 +44,7 @@ struct clrmgr_property gen6_pipe_color_corrections[] = {
 		.type = DRM_MODE_PROP_BLOB,
 		.len = VLV_CSC_MATRIX_MAX_VALS,
 		.name = "csc-correction",
+		.set_property = intel_clrmgr_set_csc,
 	},
 	{
 		.tweak_id = gamma,
@@ -87,6 +88,87 @@ struct clrmgr_property gen6_plane_color_corrections[] = {
 	}
 };
 
+/*
+* vlv_set_csc
+* Valleyview specific csc correction method.
+* Programs the 6 csc registers with 3x3 correction matrix
+* values.
+* inputs:
+* - intel_crtc*
+* - color manager registered property for csc correction
+* - data: pointer to correction values to be applied
+*/
+/* Enable color space conversion on PIPE */
+bool vlv_set_csc(struct intel_crtc *intel_crtc,
+	struct clrmgr_regd_prop *csc, u64 *data)
+{
+	u32 count = 0;
+	u32 pipeconf, csc_reg, data_size;
+	struct drm_device *dev = intel_crtc->base.dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_property *property;
+	u32 c0, c1, c2;
+
+	property = csc->property;
+	data_size = property->num_values;
+
+	/* Validate input */
+	if (data_size != VLV_CSC_MATRIX_MAX_VALS) {
+		DRM_ERROR("Unexpected value count for GAMMA LUT\n");
+		return false;
+	}
+
+	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
+	csc_reg = PIPECSC(intel_crtc->pipe);
+
+	/* Read CSC matrix, one row at a time */
+	while (count < VLV_CSC_MATRIX_MAX_VALS) {
+		c0 = data[count] & VLV_CSC_VALUE_MASK;
+		property->values[count++] = c0;
+		c1 = data[count] & VLV_CSC_VALUE_MASK;
+		property->values[count++] = c1;
+		c2 = data[count] & VLV_CSC_VALUE_MASK;
+		property->values[count++] = c2;
+
+		/* C0 is LSB 12bits, C1 is MSB 16-27 */
+		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
+		csc_reg += 4;
+
+		/* C2 is LSB 12 bits */
+		I915_WRITE(csc_reg, c2);
+		csc_reg += 4;
+	}
+
+	/* Enable csc correction */
+	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe)) | PIPECONF_CSC_ENABLE;
+	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
+	POSTING_READ(PIPECONF(intel_crtc->pipe));
+
+	DRM_DEBUG_DRIVER("CSC successfully set on pipe = %d\n",
+			intel_crtc->pipe);
+	return true;
+}
+
+bool intel_clrmgr_set_csc(void *crtc,
+	struct clrmgr_regd_prop *csc, u64 *data)
+{
+	struct intel_crtc *intel_crtc = crtc;
+	struct drm_device *dev = intel_crtc->base.dev;
+
+	/* Validate input */
+	if (!data || !csc || !csc->property) {
+		DRM_ERROR("Invalid input to set csc\n");
+		return false;
+	}
+
+	/* VLV has legacy palette gamma correction */
+	if (IS_VALLEYVIEW(dev))
+		return vlv_set_csc(intel_crtc, csc, data);
+
+	/* Todo: Support other gen devices */
+	DRM_ERROR("Color correction is supported only on VLV for now\n");
+	return false;
+}
 
 struct drm_property *intel_clrmgr_register(struct drm_device *dev,
 	struct drm_mode_object *obj, struct clrmgr_property *cp)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index 28fea24..e1279f6 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -43,6 +43,9 @@
 
 /* CSC / Wide gamut */
 #define VLV_CSC_MATRIX_MAX_VALS			9
+#define VLV_CSC_VALUE_MASK				0xFFF
+#define VLV_CSC_COEFF_SHIFT				16
+
 
 /* VLV specific gamma correction defines */
 #define VLV_10BIT_GAMMA_MAX_INDEX			128
@@ -116,6 +119,19 @@ struct clrmgr_reg_request {
 };
 
 /*
+* intel_clrmgr_set_csc
+* CSC correction method is different across various
+* gen devices. This wrapper function calls the respective
+* platform specific function to set CSC
+* inputs:
+* - crtc: void *, can be typecaseted to intel_crtc*
+* - csc: registered color property for csc correction
+* - data: pointer to correction values to be applied
+*/
+bool intel_clrmgr_set_csc(void *crtc,
+	struct clrmgr_regd_prop *csc, u64 *data);
+
+/*
 * intel_clrmgr_register_pipe_property
 * register set of properties with a CRTC
 * input:
-- 
1.9.1

[PATCH 05/11] drm/i915: Add color manager gamma correction

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patch adds support for pipe gamma correction color property
for intel color manager framework. It adds two functions:
1. intel_clrmgr_set_gamma: This is a wrapper function
   which checks the platform type, and calls the valleyview
   specific set_gamma function. As different platforms have different
   methods of setting pipe gamma, this function is required.The support for
   other platfroms can be plugged-in here in the wrapper function.
   Adding this function as .set_property of gamma-correction color property.
2. vlv_set_10_bit_gamma: Core function to program gamma coefficients as per
   vlv specs, and then enable gamma on pipe. This function uses 10-bit gamma
   programming method of VLV (10.6 method), which is more accurate, and can
   support fraction values also. Userspace encodes 16 bit per channel gamma
   correction value in 64bit value in <None><R16><G16><B16> format, and sends
   128 such gamma correction values. The 129th value is GCMAX register value.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h     |   5 ++
 drivers/gpu/drm/i915/intel_clrmgr.c | 125 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h |  29 +++++++++
 3 files changed, 159 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3199f96..9501ad8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6095,6 +6095,11 @@ enum punit_power_well {
 #define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
 #define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
 
+/* Gamma GCMAX */
+#define VLV_PIPEA_GCMAX	(dev_priv->info.display_mmio_offset + 0x70010)
+#define VLV_PIPEB_GCMAX	(dev_priv->info.display_mmio_offset + 0x71010)
+#define VLV_PIPE_GCMAX(pipe)	_PIPE(pipe, VLV_PIPEA_GCMAX, VLV_PIPEB_GCMAX)
+
 /* VLV MIPI registers */
 
 #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 601076b..38ba878 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -51,6 +51,7 @@ struct clrmgr_property gen6_pipe_color_corrections[] = {
 		.type = DRM_MODE_PROP_BLOB,
 		.len = VLV_10BIT_GAMMA_MAX_VALS,
 		.name = "gamma-correction",
+		.set_property = intel_clrmgr_set_gamma,
 	},
 };
 
@@ -89,6 +90,130 @@ struct clrmgr_property gen6_plane_color_corrections[] = {
 };
 
 /*
+* vlv_set_10bit_gamma
+* Valleyview specific gamma correction method.
+* Programs the palette registers in 10bit method
+* with 128 correction values, sampled across 1024
+* gamma correction values at sampling rate of 8.
+* inputs:
+* - intel_crtc*
+* - color manager registered property for gamma correction
+* - data: pointer to correction values to be applied
+*/
+static bool vlv_set_10bit_gamma(struct intel_crtc *intel_crtc,
+	struct clrmgr_regd_prop *gamma, u64 *data)
+{
+	u16 red, green, blue;
+	u64 correct_rgb;
+	u32 val, even, odd;
+	u32 count = 0;
+	u32 reg = 0;
+	struct drm_property *property = gamma->property;
+	struct drm_device *dev = intel_crtc->base.dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	u32 palette = PALETTE(intel_crtc->pipe);
+
+	/* Validate input */
+	if (property->num_values != VLV_10BIT_GAMMA_MAX_VALS) {
+		DRM_ERROR("Unexpected value count for GAMMA LUT");
+		return false;
+	}
+
+	/* 128, 64 bit values, coming in <0><R16><G16><B16> format containing
+	only 10 integer and 6fraction correction values */
+	while (count < (property->num_values - CLRMGR_GAMMA_GCMAX_VAL)) {
+		correct_rgb = data[count];
+		property->values[count] = correct_rgb;
+
+		blue =  correct_rgb >> CLRMGR_GAMMA_PARSER_SHIFT_BLUE;
+		green = correct_rgb >> CLRMGR_GAMMA_PARSER_SHIFT_GREEN;
+		red = correct_rgb >> CLRMGR_GAMMA_PARSER_SHIFT_RED;
+
+		/* Prepare even and odd regs. Even register contains 6
+		fractional and 2 integer base bits, so lower 8 bits */
+		even =  ((blue & VLV_GAMMA_EVEN_MASK) <<
+				VLV_GAMMA_SHIFT_BLUE_REG) |
+			((green & VLV_GAMMA_EVEN_MASK) <<
+				VLV_GAMMA_SHIFT_GREEN_REG) |
+			((red & VLV_GAMMA_EVEN_MASK) <<
+				VLV_GAMMA_SHIFT_RED_REG);
+
+		/* Odd register contains upper 8 (integer) bits */
+		odd = ((blue >> VLV_GAMMA_ODD_SHIFT) <<
+				VLV_GAMMA_SHIFT_BLUE_REG) |
+			((green >> VLV_GAMMA_ODD_SHIFT) <<
+				VLV_GAMMA_SHIFT_GREEN_REG) |
+			((red >> VLV_GAMMA_ODD_SHIFT) <<
+				VLV_GAMMA_SHIFT_RED_REG);
+
+		/* Writing fraction part first, then integer part */
+		I915_WRITE(palette, even);
+		palette += 4;
+		I915_WRITE(palette, odd);
+		palette += 4;
+		count++;
+	}
+
+	/* Last 64bit values is in 11.6 format for GCmax, RGB sequence */
+	correct_rgb = data[count];
+	property->values[count] = correct_rgb;
+
+	count = CLRMGR_GAMMA_TOTAL_GCMAX_REGS;
+	reg = VLV_PIPE_GCMAX(intel_crtc->pipe);
+	while (count--) {
+		val = (correct_rgb >> (count * VLV_CLRMGR_GAMMA_GCMAX_SHIFT)) &
+			VLV_GAMMA_GCMAX_MASK;
+		/* GCMAX value must be <= 1024 */
+		if (val > VLV_CLRMGR_GAMMA_GCMAX_MAX)
+			val = VLV_CLRMGR_GAMMA_GCMAX_MAX;
+
+		/* Write in 11.6 format */
+		I915_WRITE(reg, (val << 6));
+		reg += 4;
+	}
+
+	/* Enable gamma for PIPE */
+	reg = PIPECONF(intel_crtc->pipe);
+	val = I915_READ(reg) | PIPECONF_GAMMA;
+	I915_WRITE(reg, val);
+
+	/* Enable gamma for sprites */
+	for_each_sprite(intel_crtc->pipe, count) {
+		reg = SPCNTR(intel_crtc->pipe, count);
+		val = I915_READ(reg) | SPRITE_GAMMA_ENABLE;
+		I915_WRITE(reg, val);
+	}
+
+	DRM_DEBUG_DRIVER("10bit gamma correction successfully applied");
+	return true;
+}
+
+bool intel_clrmgr_set_gamma(void *crtc,
+		struct clrmgr_regd_prop *gamma, u64 *data)
+{
+	struct intel_crtc *intel_crtc = crtc;
+	struct drm_device *dev = intel_crtc->base.dev;
+
+	/* Validate input */
+	if (!data || !gamma || !gamma->property) {
+		DRM_ERROR("Invalid input to set_gamma\n");
+		return false;
+	}
+
+	DRM_DEBUG_DRIVER("Setting gamma correction, len=%d\n",
+		gamma->property->num_values);
+
+	/* VLV has legacy palette gamma correction */
+	if (IS_VALLEYVIEW(dev))
+		return vlv_set_10bit_gamma(intel_crtc, gamma, data);
+
+	/* Todo: Support other gen devices */
+	DRM_ERROR("Color correction is supported only on VLV for now\n");
+	return false;
+}
+
+
+/*
 * vlv_set_csc
 * Valleyview specific csc correction method.
 * Programs the 6 csc registers with 3x3 correction matrix
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index e1279f6..fd8b98e 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -40,6 +40,12 @@
 #define CLRMGR_PROP_NAME_MAX				128
 #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
 
+/* Gamma correcttion */
+#define CLRMGR_GAMMA_PARSER_SHIFT_BLUE			0
+#define CLRMGR_GAMMA_PARSER_SHIFT_GREEN		16
+#define CLRMGR_GAMMA_PARSER_SHIFT_RED			32
+#define CLRMGR_GAMMA_TOTAL_GCMAX_REGS			3
+#define CLRMGR_GAMMA_MAX_SAMPLES			1024
 
 /* CSC / Wide gamut */
 #define VLV_CSC_MATRIX_MAX_VALS			9
@@ -52,6 +58,16 @@
 #define CLRMGR_GAMMA_GCMAX_VAL				1
 #define VLV_10BIT_GAMMA_MAX_VALS		(VLV_10BIT_GAMMA_MAX_INDEX + \
 						CLRMGR_GAMMA_GCMAX_VAL)
+#define VLV_GAMMA_EVEN_MASK				0xFF
+#define VLV_GAMMA_SHIFT_BLUE_REG		0
+#define VLV_GAMMA_SHIFT_GREEN_REG		8
+#define VLV_GAMMA_SHIFT_RED_REG			16
+#define VLV_GAMMA_ODD_SHIFT			8
+#define VLV_CLRMGR_GAMMA_GCMAX_SHIFT			17
+#define VLV_GAMMA_GCMAX_MASK				0x1FFFF
+#define VLV_CLRMGR_GAMMA_GCMAX_MAX			0x400
+
+
 
 /* Sprite Contrast and Brightness Registers */
 #define VLV_CB_MAX_VALS				1
@@ -119,6 +135,19 @@ struct clrmgr_reg_request {
 };
 
 /*
+* intel_clrmgr_set_gamma
+* Gamma correction method is different across various
+* gen devices. This is a wrapper function which will call
+* the platform specific gamma set function
+* inputs:
+* - crtc : void *, which can be typecasted to intel_crtc*
+* - gamma: registered color property for gamma correction
+* - data: pointer to correction values to be applied
+*/
+bool intel_clrmgr_set_gamma(void *crtc,
+		struct clrmgr_regd_prop *gamma, u64 *data);
+
+/*
 * intel_clrmgr_set_csc
 * CSC correction method is different across various
 * gen devices. This wrapper function calls the respective
-- 
1.9.1

[PATCH 06/11] drm/i915: Add contrast and brightness correction

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patch adds support for color property to set sprite plane
contrast and brightness for intel color manager framework.
As, in valleyview the register for contrast and brightess
adjustment is same, one common function has been added to serve
both. It adds three functions:
  1. intel_clrmgr_set_contrast: This is a wrapper function
     which checks the platform type, and calls the valleyview
     specific set_contrast function. As different platforms have different
     methods of setting contrast, this function is required.The support for
     other platfroms can be plugged-in here in the wrapper function.
     Adding this function as .set_property for contrast and brightness
     color properties.
  2. intel_clrmgr_set_brightness: This is again a wrapper function for
     brightness setting.
  3. vlv_set_cb: Core function to program brightness/contrast as per
     vlv specs. This function takes one 64bit value as input, and extracts
     contrast/brightness values, and applies.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h     |  3 ++
 drivers/gpu/drm/i915/intel_clrmgr.c | 84 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h | 38 ++++++++++++++++-
 3 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9501ad8..414a113 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6100,6 +6100,9 @@ enum punit_power_well {
 #define VLV_PIPEB_GCMAX	(dev_priv->info.display_mmio_offset + 0x71010)
 #define VLV_PIPE_GCMAX(pipe)	_PIPE(pipe, VLV_PIPEA_GCMAX, VLV_PIPEB_GCMAX)
 
+/* Contrast and brightness */
+#define VLV_SPRITE_CB_BASE	(dev_priv->info.display_mmio_offset + 0x721d0)
+
 /* VLV MIPI registers */
 
 #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 38ba878..781df59 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -70,6 +70,7 @@ struct clrmgr_property gen6_plane_color_corrections[] = {
 		.min = 0,
 		.len = VLV_CB_MAX_VALS,
 		.name = "contrast",
+		.set_property = intel_clrmgr_set_contrast,
 	},
 	{
 		.tweak_id = brightness,
@@ -78,6 +79,7 @@ struct clrmgr_property gen6_plane_color_corrections[] = {
 		.min = 0,
 		.len = VLV_CB_MAX_VALS,
 		.name = "brightness",
+		.set_property = intel_clrmgr_set_brightness,
 	},
 	{
 		.tweak_id = hue_saturation,
@@ -90,6 +92,88 @@ struct clrmgr_property gen6_plane_color_corrections[] = {
 };
 
 /*
+* vlv_set_cb
+* Valleyview specific common functtion for contsrast/brightness
+* setting. The method and registes are same for both.
+* Valleyview supports contrast/brightness correction only on
+* sprite planes.
+* inputs:
+* - intel_crtc *
+* - cb: registered property for contrast.
+* - data: value to be applied
+*/
+bool vlv_set_cb(struct intel_plane *intel_plane, struct clrmgr_regd_prop *cb,
+	u64 *data, enum clrmgr_tweaks tweak)
+{
+
+	u32 val, new_val, reg, sprite;
+	struct drm_device *dev = intel_plane->base.dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_property *property = cb->property;
+
+	sprite = intel_plane->plane;
+	if (!(SPCNTR(intel_plane->pipe, sprite) & SP_ENABLE)) {
+		DRM_ERROR("Sprite plane %d not enabled\n", sprite);
+		return false;
+	}
+
+	/* Apply correction only if sprite is enabled */
+	DRM_DEBUG_DRIVER("Applying cb correction on Sprite\n");
+	reg = SPRITE_CB(intel_plane->pipe, sprite);
+
+	if (tweak == contrast) {
+		/* Contrast value is lower 9 bit value */
+		new_val = *data & VLV_CONTRAST_MASK;
+		DRM_DEBUG_DRIVER("Setting Contrast to 0x%x", new_val);
+
+		/* Contrast correction position is bit [26:18] */
+		val = I915_READ(reg) &
+			~(VLV_CONTRAST_MASK << VLV_CONTRAST_SHIFT);
+		val |= (new_val << VLV_CONTRAST_SHIFT);
+	} else {
+		new_val = *data & VLV_BRIGHTNESS_MASK;
+		DRM_DEBUG_DRIVER("Setting Brightness to 0x%x", new_val);
+
+		/* Brightness correction is lower 8 [7:0] register bits */
+		val = I915_READ(reg) | new_val;
+	}
+
+	/* Contrast and brightness are single value properties */
+	I915_WRITE(reg, val);
+	property->values[property->num_values - 1] = *data;
+	DRM_DEBUG_DRIVER("Set Contrast/Brightness correction successful");
+	return true;
+}
+
+bool intel_clrmgr_set_brightness(void *plane,
+	struct clrmgr_regd_prop *bright, u64 *data)
+{
+	struct intel_plane *intel_plane = plane;
+	struct drm_device *dev = intel_plane->base.dev;
+
+	if (IS_VALLEYVIEW(dev))
+		return vlv_set_cb(intel_plane, bright, data, brightness);
+
+	/* Todo: Support other gen devices */
+	DRM_ERROR("Color correction is supported only on VLV for now\n");
+	return false;
+}
+
+bool intel_clrmgr_set_contrast(void *plane,
+	struct clrmgr_regd_prop *ctrst, u64 *data)
+{
+	struct intel_plane *intel_plane = plane;
+	struct drm_device *dev = intel_plane->base.dev;
+
+	if (IS_VALLEYVIEW(dev))
+		return vlv_set_cb(intel_plane, ctrst, data, contrast);
+
+	/* Todo: Support other gen devices */
+	DRM_ERROR("Color correction is supported only on VLV for now\n");
+	return false;
+}
+
+/*
 * vlv_set_10bit_gamma
 * Valleyview specific gamma correction method.
 * Programs the palette registers in 10bit method
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index fd8b98e..d1fc787 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -67,10 +67,16 @@
 #define VLV_GAMMA_GCMAX_MASK				0x1FFFF
 #define VLV_CLRMGR_GAMMA_GCMAX_MAX			0x400
 
+/* Offset for sprite planes */
+#define SPRITE_COLOR_OFFSET				0x100
 
-
-/* Sprite Contrast and Brightness Registers */
+/* Sprite Contrast and Brightness common defs */
 #define VLV_CB_MAX_VALS				1
+#define SPRITE_CB(p, s)				(VLV_SPRITE_CB_BASE + \
+					(p * 2 + s) * SPRITE_COLOR_OFFSET)
+#define VLV_CONTRAST_MASK				0x1FF
+#define VLV_CONTRAST_SHIFT				18
+#define VLV_BRIGHTNESS_MASK				0xFF
 
 /* Sprite Hue and Saturation Registers */
 #define VLV_HS_MAX_VALS				1
@@ -135,6 +141,34 @@ struct clrmgr_reg_request {
 };
 
 /*
+* intel_clrmgr_set_contrast
+* Set contrast level.
+* Different gen devices have different methods for
+* contrast setting. This is a wrapper function to
+* call device specific set contrast function
+* inputs:
+* - plane: void*, can be typecasted to intel_plane*
+* - ctrst: registered color property for contrast
+* - data: new value
+*/
+bool intel_clrmgr_set_contrast(void *plane,
+	struct clrmgr_regd_prop *ctrst, u64 *data);
+
+/*
+* intel_clrmgr_set_brightness
+* Set brightness level.
+* Different gen devices have different methods for
+* brightness setting. This is a wrapper function to
+* call device specific set brightess function
+* inputs:
+* - plane: void*, can be typecasted to intel_plane*
+* - bright: registered color property for brightness
+* - data: new value
+*/
+bool intel_clrmgr_set_brightness(void *plane,
+	struct clrmgr_regd_prop *bright, u64 *data);
+
+/*
 * intel_clrmgr_set_gamma
 * Gamma correction method is different across various
 * gen devices. This is a wrapper function which will call
-- 
1.9.1

[PATCH 07/11] drm/i915: Add hue and saturation correction

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patch adds support for color property to set sprite plane
hue and saturation values, for intel color manager framework.
It adds two functions:
  1. intel_clrmgr_set_hue_sat: This is a wrapper function
     which checks the platform type, and calls the valleyview
     specific set_hue_saturation function. As different platforms have different
     methods of setting hue/saturation, this function is required.The support for
     other platfroms can be plugged-in here in the wrapper function.
     Adding this function as .set_property for hue and saturation color properties.
  2. vlv_set_hs: Core function to program hue/saturation values as per
     vlv specs. This function expects one 32bit value as input, encoded in exact
     register format, and applies it.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h     |  3 ++
 drivers/gpu/drm/i915/intel_clrmgr.c | 57 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h | 17 +++++++++++
 3 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 414a113..7614a0f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6103,6 +6103,9 @@ enum punit_power_well {
 /* Contrast and brightness */
 #define VLV_SPRITE_CB_BASE	(dev_priv->info.display_mmio_offset + 0x721d0)
 
+/* Hue and saturation */
+#define VLV_SPRITE_HS_BASE	(dev_priv->info.display_mmio_offset + 0x721d4)
+
 /* VLV MIPI registers */
 
 #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 781df59..a4c8f0f 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -88,10 +88,67 @@ struct clrmgr_property gen6_plane_color_corrections[] = {
 		.min = 0,
 		.len = VLV_HS_MAX_VALS,
 		.name = "hue-saturation",
+		.set_property = intel_clrmgr_set_hue_sat,
 	}
 };
 
 /*
+* vlv_set_hs
+* Valleyview specific hue/saturation setting function.
+* Valleyview supports hue/saturation correction only on
+* sprite planes.
+* inputs:
+* - intel_crtc *
+* - hs: registered property for hue/sat. This encapsulates a drm_property
+*	which is common for all sprite planes. The property has entries equal
+*	to no of sprite planes in valleyview = 2
+* -data: 64 bit encoded values, low 32 bits contain the new contrast/
+	brightness values, whereas the upper 32 bits contain the sprite no.
+*/
+bool vlv_set_hs(struct intel_plane *intel_plane, struct clrmgr_regd_prop *hs,
+	uint64_t *data)
+{
+
+	u32 new_val, reg, sprite;
+	struct drm_device *dev = intel_plane->base.dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_property *property = hs->property;
+
+	sprite = intel_plane->plane;
+
+	/* If plane enabled */
+	if (!(SPCNTR(intel_plane->pipe, sprite) & SP_ENABLE)) {
+			DRM_ERROR("Sprite plane %d not enabled\n", sprite);
+			return false;
+	}
+
+	/* Apply correction */
+	DRM_DEBUG_DRIVER("Applying hs correction on Sprite\n");
+	reg = SPRITE_HS(intel_plane->pipe, sprite);
+	new_val = *data;
+
+	/* Contrast and brightness are single value properties */
+	I915_WRITE(reg, new_val);
+	property->values[property->num_values - 1] = *data;
+	DRM_DEBUG_DRIVER("Set Hue/Saturation to 0x%x successful\n", new_val);
+	return true;
+}
+
+bool intel_clrmgr_set_hue_sat(void *plane,
+	struct clrmgr_regd_prop *hs, u64 *data)
+{
+	struct intel_plane *intel_plane = plane;
+	struct drm_device *dev = intel_plane->base.dev;
+
+	if (IS_VALLEYVIEW(dev))
+		return vlv_set_hs(intel_plane, hs, data);
+
+	/* Todo: Support other gen devices */
+	DRM_ERROR("Color correction is supported only on VLV for now\n");
+	return false;
+}
+
+/*
 * vlv_set_cb
 * Valleyview specific common functtion for contsrast/brightness
 * setting. The method and registes are same for both.
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index d1fc787..6d316d2 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -80,6 +80,9 @@
 
 /* Sprite Hue and Saturation Registers */
 #define VLV_HS_MAX_VALS				1
+#define SPRITE_HS(p, s)				(VLV_SPRITE_HS_BASE +  \
+					((p * 2 + s) * SPRITE_COLOR_OFFSET))
+
 
 /* Color manager features */
 enum clrmgr_tweaks {
@@ -169,6 +172,20 @@ bool intel_clrmgr_set_brightness(void *plane,
 	struct clrmgr_regd_prop *bright, u64 *data);
 
 /*
+* intel_clrmgr_set_hue-sat
+* Set contrast level.
+* Different gen devices have different methods for
+* contrast setting. This is a wrapper function to
+* call device specific set contrast function
+* inputs:
+* - plane: void*, can be typecasted to intel_plane*
+* - hs: registered color property for hue and saturation
+* - data: new value
+*/
+bool intel_clrmgr_set_hue_sat(void *plane,
+	struct clrmgr_regd_prop *hs, u64 *data);
+
+/*
 * intel_clrmgr_set_gamma
 * Gamma correction method is different across various
 * gen devices. This is a wrapper function which will call
-- 
1.9.1

[PATCH 08/11] drm/i915: Add CRTC set property functions

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Color manager's pipe level correction properties are
registered as CRTC property. So its required to have a
.set_crtc function in CRTC functions.

This patch adds:
1. A .set_property function for intel_crtc, intel_crtc_set_property
   which checks if a CRTC property is of type color property, it
   calls color manager's pipe level set_property handler function.
2. A intel_clrmgr_set_pipe_property, which will extract the data
   to be set, and then pass it to appropriate set_property function.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_clrmgr.c  | 47 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h  | 11 +++++++++
 drivers/gpu/drm/i915/intel_display.c | 45 ++++++++++++++++++++++++++++++++++
 3 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index a4c8f0f..eb18ee2 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -654,6 +654,53 @@ intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
 	kfree(features);
 }
 
+bool intel_clrmgr_set_pipe_property(struct intel_crtc *intel_crtc,
+		struct clrmgr_regd_prop *cp, uint64_t value)
+{
+	bool ret = false;
+	uint64_t *data;
+	struct drm_property *property;
+
+	/* Sanity */
+	if (!cp->property) {
+		DRM_ERROR("NULL input to set_property\n");
+		return false;
+	}
+
+	property = cp->property;
+	DRM_DEBUG_DRIVER("Property %s len:%d\n",
+		cp->property->name, cp->property->num_values);
+	data = kmalloc(sizeof(uint64_t) * (property->num_values), GFP_KERNEL);
+	if (!data) {
+		DRM_ERROR("Out of memory\n");
+		return false;
+	}
+
+	if (copy_from_user((void *)data, (const void __user *)value,
+			property->num_values * sizeof(uint64_t))) {
+		DRM_ERROR("Failed to copy all data\n");
+		ret = false;
+		goto free_and_return;
+	}
+
+	/* Now do the actual work */
+	if (cp->set_property) {
+		if (!cp->set_property((void *)intel_crtc, cp, data)) {
+			DRM_ERROR("Set property for %s failed\n",
+					cp->property->name);
+			ret = false;
+		} else {
+			ret = true;
+			cp->enabled = true;
+			DRM_DEBUG_DRIVER("Set property %s successful\n",
+				cp->property->name);
+		}
+	}
+free_and_return:
+	kfree(data);
+	return ret;
+}
+
 struct clrmgr_status *intel_clrmgr_init(struct drm_device *dev)
 {
 	struct clrmgr_status *status;
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index 6d316d2..d962585 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -212,6 +212,17 @@ bool intel_clrmgr_set_csc(void *crtc,
 	struct clrmgr_regd_prop *csc, u64 *data);
 
 /*
+* intel_clrmgr_set_pipe_property
+* Set value of a registered CRTC property
+* input:
+* - intel_crtc: the CRTC with which the property is attached
+* - cp: registered color property
+* - value: value to be set
+*/
+bool intel_clrmgr_set_pipe_property(struct intel_crtc *intel_crtc,
+		struct clrmgr_regd_prop *cp, uint64_t value);
+
+/*
 * intel_clrmgr_register_pipe_property
 * register set of properties with a CRTC
 * input:
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 99eb7ca..a6181b5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -42,6 +42,7 @@
 #include <drm/drm_plane_helper.h>
 #include <drm/drm_rect.h>
 #include <linux/dma_remapping.h>
+#include "intel_clrmgr.h"
 
 /* Primary plane formats supported by all gen */
 #define COMMON_PRIMARY_FORMATS \
@@ -8438,6 +8439,49 @@ mode_fits_in_fbdev(struct drm_device *dev,
 #endif
 }
 
+/*
+* intel_crtc_set_property
+* Set a CRTC property, like color tweaks
+*/
+static int intel_crtc_set_property(struct drm_crtc *crtc,
+			    struct drm_property *property, uint64_t val)
+{
+	int ret = 0;
+	int count = 0;
+	struct clrmgr_regd_prop *cp;
+	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+	struct clrmgr_status *status = intel_crtc->color_status;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	/* Is this color property ?*/
+	if (!status) {
+		DRM_DEBUG_DRIVER("Color manager not initialized\n");
+		ret = -1;
+		goto skip_color;
+	}
+
+	/* Color correction property */
+	while (count < status->no_of_properties) {
+		cp = status->cp[count++];
+		if (property == cp->property) {
+			/* Found it, now set it */
+			if (intel_clrmgr_set_pipe_property(intel_crtc,
+				cp, val)) {
+				DRM_DEBUG_DRIVER("Set property %s successful\n",
+					property->name);
+				return 0;
+			} else {
+				DRM_ERROR("Set CRTC property %s failed\n",
+					property->name);
+				return -1;
+			}
+		}
+	}
+skip_color:
+	return ret;
+}
+
 bool intel_get_load_detect_pipe(struct drm_connector *connector,
 				struct drm_display_mode *mode,
 				struct intel_load_detect_pipe *old,
@@ -11347,6 +11391,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
 	.set_config = intel_crtc_set_config,
 	.destroy = intel_crtc_destroy,
 	.page_flip = intel_crtc_page_flip,
+	.set_property = intel_crtc_set_property,
 };
 
 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
-- 
1.9.1

[PATCH 09/11] drm/i915: Add set plane property functions

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Color manager's plane level correction properties are
registered as plane property. So its required to have a
.set_property function in plane functions.

This patch adds:
1. A .set_property function for intel_plane, intel_plane_set_property
   which checks if a plane property is of type color property, it
   calls color manager's plane level set_property handler function.
2. A intel_clrmgr_set_plane_property, which will extract the data
   to be set, and then pass it to appropriate set_property function

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_clrmgr.c | 47 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h | 11 +++++++++
 drivers/gpu/drm/i915/intel_sprite.c | 41 ++++++++++++++++++++++++++++++++
 3 files changed, 99 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index eb18ee2..d0d952b 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -654,6 +654,53 @@ intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
 	kfree(features);
 }
 
+bool intel_clrmgr_set_plane_property(struct intel_plane *intel_plane,
+		struct clrmgr_regd_prop *cp, uint64_t value)
+{
+	bool ret = false;
+	uint64_t *data;
+	struct drm_property *property;
+
+	/* Sanity */
+	if (!cp->property) {
+		DRM_ERROR("NULL input to set_property\n");
+		return false;
+	}
+
+	property = cp->property;
+	DRM_DEBUG_DRIVER("Property %s len:%d\n",
+		cp->property->name, cp->property->num_values);
+	data = kmalloc(sizeof(uint64_t) * (property->num_values), GFP_KERNEL);
+	if (!data) {
+		DRM_ERROR("Out of memory\n");
+		return false;
+	}
+
+	if (copy_from_user((void *)data, (const void __user *)value,
+			property->num_values * sizeof(uint64_t))) {
+		DRM_ERROR("Failed to copy all data\n");
+		ret = false;
+		goto free_and_return;
+	}
+
+	/* Now do the actual work */
+	if (cp->set_property) {
+		if (!cp->set_property((void *)intel_plane, cp, data)) {
+			DRM_ERROR("Set property for %s failed\n",
+				cp->property->name);
+			ret = false;
+		} else {
+			ret = true;
+			cp->enabled = true;
+			DRM_DEBUG_DRIVER("Set property %s successful\n",
+				cp->property->name);
+		}
+	}
+free_and_return:
+	kfree(data);
+	return ret;
+}
+
 bool intel_clrmgr_set_pipe_property(struct intel_crtc *intel_crtc,
 		struct clrmgr_regd_prop *cp, uint64_t value)
 {
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index d962585..c1de823 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -212,6 +212,17 @@ bool intel_clrmgr_set_csc(void *crtc,
 	struct clrmgr_regd_prop *csc, u64 *data);
 
 /*
+* intel_clrmgr_set_plane_property
+* Set value of a registered plane property
+* input:
+* - intel_plane: the plane with which the property is attached
+* - cp: registered color property
+* - value: value to be set
+*/
+bool intel_clrmgr_set_plane_property(struct intel_plane *intel_plane,
+		struct clrmgr_regd_prop *cp, uint64_t value);
+
+/*
 * intel_clrmgr_set_pipe_property
 * Set value of a registered CRTC property
 * input:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 168c665..affb429 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -36,6 +36,7 @@
 #include "intel_drv.h"
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
+#include "intel_clrmgr.h"
 
 static int usecs_to_scanlines(const struct drm_display_mode *mode, int usecs)
 {
@@ -1180,6 +1181,45 @@ out_unlock:
 	return ret;
 }
 
+int intel_plane_set_property(struct drm_plane *plane,
+	struct drm_property *property, uint64_t val)
+{
+	int ret = 0;
+	int count = 0;
+	struct clrmgr_regd_prop *cp;
+	struct intel_plane *intel_plane = to_intel_plane(plane);
+	struct clrmgr_status *status = intel_plane->color_status;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	/* Is this color property ?*/
+	if (!status) {
+		DRM_DEBUG_DRIVER("Color manager not initialized\n");
+		ret = -1;
+		goto skip_color;
+	}
+
+	/* Color manager property */
+	while (count < status->no_of_properties) {
+		cp = status->cp[count++];
+		if (property == cp->property) {
+			/* Found it, now set it */
+			if (intel_clrmgr_set_plane_property(intel_plane,
+				cp, val)) {
+				DRM_DEBUG_DRIVER("Set property %s successful\n",
+					property->name);
+				return 0;
+			} else {
+				DRM_ERROR("Set CRTC property %s failed\n",
+					property->name);
+				return -1;
+			}
+		}
+	}
+skip_color:
+	return ret;
+}
+
 void intel_plane_restore(struct drm_plane *plane)
 {
 	struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -1206,6 +1246,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
 	.update_plane = intel_update_plane,
 	.disable_plane = intel_disable_plane,
 	.destroy = intel_destroy_plane,
+	.set_property = intel_plane_set_property
 };
 
 static uint32_t ilk_plane_formats[] = {
-- 
1.9.1

[PATCH 10/11] drm/i915: Plug-in color manager init

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Call color manager init and attach color properties
during the pipe and plane init time. This will register
all pipe level properties with each intel_crtc and all plane
level properties with each intel_plane objects.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_clrmgr.c  | 67 ++++++++++++++++++------------------
 drivers/gpu/drm/i915/intel_clrmgr.h  | 11 +++++-
 drivers/gpu/drm/i915/intel_display.c |  4 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  3 ++
 4 files changed, 51 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index d0d952b..ab38fab 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -532,39 +532,6 @@ error:
 	return false;
 }
 
-void
-intel_attach_plane_color_correction(struct intel_plane *intel_plane)
-{
-	struct clrmgr_reg_request *features;
-
-	/* Color manager initialized? */
-	if (!intel_plane->color_status) {
-		DRM_ERROR("Color manager not initialized for plane %d\n",
-			intel_plane->plane);
-		return;
-	}
-
-	DRM_DEBUG_DRIVER("\n");
-	features = kzalloc(sizeof(struct clrmgr_reg_request), GFP_KERNEL);
-	if (!features) {
-		DRM_ERROR("No memory for plane color features\n");
-		return;
-	}
-
-	features->no_of_properties = ARRAY_SIZE(gen6_plane_color_corrections);
-	memcpy(features->cp, gen6_plane_color_corrections,
-				features->no_of_properties *
-					sizeof(struct clrmgr_property));
-
-	/* Register plane level color properties */
-	if (!intel_clrmgr_register_plane_property(intel_plane, features))
-		DRM_ERROR("Register plane color property failed\n");
-	else
-		DRM_DEBUG_DRIVER("Attached colot corrections for plane %d\n",
-			intel_plane->plane);
-	kfree(features);
-}
-
 bool intel_clrmgr_register_pipe_property(struct intel_crtc *intel_crtc,
 		struct clrmgr_reg_request *features)
 
@@ -623,6 +590,40 @@ error:
 }
 
 void
+intel_attach_plane_color_correction(struct intel_plane *intel_plane)
+{
+	struct clrmgr_reg_request *features;
+
+	/* Color manager initialized? */
+	if (!intel_plane->color_status) {
+		DRM_ERROR("Color manager not initialized for plane %d\n",
+			intel_plane->plane);
+		return;
+	}
+
+	DRM_DEBUG_DRIVER("\n");
+	features = kzalloc(sizeof(struct clrmgr_reg_request), GFP_KERNEL);
+	if (!features) {
+		DRM_ERROR("No memory for plane color features\n");
+		return;
+	}
+
+	features->no_of_properties = ARRAY_SIZE(gen6_plane_color_corrections);
+	memcpy(features->cp, gen6_plane_color_corrections,
+				features->no_of_properties *
+					sizeof(struct clrmgr_property));
+
+	/* Register plane level color properties */
+	if (!intel_clrmgr_register_plane_property(intel_plane, features))
+		DRM_ERROR("Register plane color property failed\n");
+	else
+		DRM_DEBUG_DRIVER("Attached colot corrections for plane %d\n",
+			intel_plane->plane);
+	kfree(features);
+}
+
+
+void
 intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
 {
 	struct clrmgr_reg_request *features;
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index c1de823..c78d1db 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -244,8 +244,17 @@ bool intel_clrmgr_register_pipe_property(struct intel_crtc *intel_crtc,
 		struct clrmgr_reg_request *features);
 
 /*
+* intel_attach_plane_color_correction:
+* Register color correction properties as plane properties
+* input:
+* - intel_plane : plane to attach color correcection with
+*/
+void
+intel_attach_plane_color_correction(struct intel_plane *intel_plane);
+
+/*
 * intel_attach_pipe_color_correction:
-* Register color correction properties as DRM CRTC properties
+* Register color correction properties as CRTC properties
 * input:
 * - intel_crtc : CRTC to attach color correcection with
 */
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index a6181b5..81d9002 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11835,6 +11835,10 @@ static void intel_crtc_init(struct drm_device *dev, int pipe)
 		intel_crtc->plane = !pipe;
 	}
 
+	/* Register color properties */
+	intel_crtc->color_status = intel_clrmgr_init(dev);
+	intel_attach_pipe_color_correction(intel_crtc);
+
 	intel_crtc->cursor_base = ~0;
 	intel_crtc->cursor_cntl = ~0;
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index affb429..8fb704c 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1359,5 +1359,8 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
 	if (ret)
 		kfree(intel_plane);
 
+	/* Register color properties */
+	intel_plane->color_status = intel_clrmgr_init(dev);
+	intel_attach_plane_color_correction(intel_plane);
 	return ret;
 }
-- 
1.9.1

[PATCH 11/11] drm/i915: Plug-in color manager exit

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Call color manager exit from the CRTC destroy/ plane destroy
function to free all the allocated memory, and cleanup all
the registered DRM properties.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 drivers/gpu/drm/i915/intel_sprite.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 81d9002..6babcc5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9144,6 +9144,7 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
 		kfree(work);
 	}
 
+	intel_clrmgr_exit(crtc->dev, intel_crtc->color_status);
 	drm_crtc_cleanup(crtc);
 
 	kfree(intel_crtc);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 32aa6e9..44504b1 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1119,6 +1119,7 @@ static void intel_destroy_plane(struct drm_plane *plane)
 {
 	struct intel_plane *intel_plane = to_intel_plane(plane);
 	intel_disable_plane(plane);
+	intel_clrmgr_exit(plane->dev, intel_plane->color_status);
 	drm_plane_cleanup(plane);
 	kfree(intel_plane);
 }
-- 
1.9.1

Re: [PATCH 00/11]: Color manager framework for I915 driver

[Daniel Vetter]

On Wed, Jul 23, 2014 at 11:34:54PM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> This patchset adds color-manager, a new framework in I915 driver which
> adds color correction and tweak capabilities in the driver.
> 
> Color manager creates a DRM propery based interface for each color
> correction, and based on the property type, registers it with each
> CRTC/plane available. 
> 
> The current implementation is for valleyview family.
> Valleyview supports following color correction properties:
> 1. CSC correction (wide gamut): This is a pipe level correction.
> There are total 9 correction coefficients in form of a 3x3 matrix,
> which are to be programmed on 6 correction registers. CSC correction
> 
> 2. Gamma correction: This is also pipe level correction
> There are total 256 palette registers, which can be programmed with
> 128 correction values, in 10.6 (10bit) format. The expected color
> Correction can be applied using 129, 64 bit correction values.
> First 128 correction values are to program palette, 129th value is for 
> GCMAX register value.
> correction format in a 64 bit value is: 
> | <16 higher bits>| <16bit R value>|<16 bit G value>|<16 bit B value>|
> 
> 3. Contrast: This is sprite plane level correction
> Expected correction value is 9 bit value
> Driver expects values in this format:
> |bits 64:32 | bits 31:9 | 8:0 contrast correction value|
> 
> 4. Brightness: This is also a sprite level correction
> Expected correction value is 8 bit value
> Driver expects values in this format:
> |bits 64:32 | bits 31:8 | 7:0 9 bit brightness correction value|
> 
> 5. Hue and saturation: This is also a sprite level correction
> Expected correction value is 32 bit value
> Driver expects values in this format:
> |bits 64:32| bits 31:0 hs correction value|
> 
> Patches:
> 1. First three patches create the basic framework.
> 2. Next 4 add functions to do color correction per property.
> 3. Next 2 add interface to set property.
> 4. last 2 patches plug-in init and exit in modeset sequences.
> 
> Shashank Sharma (11):
>   drm/i915: Color manager framework for valleyview
>   drm/i915: Register pipe level color properties
>   drm/i915: Register plane level color properties

So you're now using drm properties instead of a private ioctl, which is
good. But there's still this entire indirection through the color manager
and I don't understand it at all and what it serves us. From what I can
see it only makes the code more complex. The basic drm approach for
properties is

- Create the property once per device. If we standardize it, then it
  should be created in drm_device->mode_config, otherwise at a suitable
  place in our driver private structure.

- Link up that property with the right kms objects in the relevant init
  functions. That needs a pointer on each object to store that
  association.

- Match for these properties in the set_prop callback.

Please explain why is not sufficient with this basic&straightforward
approach and what the color manager adds in value to this. Thus far I
think we can just rip out the color manager without loss of functionality.

>   drm/i915: Add color manager CSC correction
>   drm/i915: Add color manager gamma correction

We already have gamma support in core drm, so we shouldn't duplicate
things. There's a few things we need to do though:
- Convert gamma to be a property from the special-purpose ioctl it is
  currently.
- Add an enum property with all the gamma table formats support. Default
  would be the 256 entry 8 bit table.
- Add new table layout for vlv.
- Implement the new layout and switch between high-res and legacy gamma
  table appropriately.

Note that the gamma table should be flexible enough to also support the
high-res gamma tables on big cores. Or any other gpu fwiw.

>   drm/i915: Add contrast and brightness correction
>   drm/i915: Add hue and saturation correction

These 4 properties should imo all be drm core properties registered in
drm_device->mode_config, with a setup function for all four.

Also the commit message still talk about the old design where you split up
a 64 bit value. That's highly confusing. And all the indirection needs to
be ripped out (see my above comment about the color manager).

Finally we already have a few sprite properties exposed as ioctls on vlv.
I'd like those to be converted to real properties as part of this work if
possible.

For a suitable merge stragety I think it would be good to split up this
work into different parts:
- Convert existing ioctl properties.
- Gamma table improvements.
- Color adjustements (brightness, contrast, hue, saturation).
- CSC.

Cheers, Daniel

>   drm/i915: Add CRTC set property functions
>   drm/i915: Add set plane property functions
>   drm/i915: Plug-in color manager init
>   drm/i915: Plug-in color manager exit
> 
>  drivers/gpu/drm/i915/Makefile        |   3 +-
>  drivers/gpu/drm/i915/i915_reg.h      |  22 +
>  drivers/gpu/drm/i915/intel_clrmgr.c  | 795 +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_clrmgr.h  | 282 +++++++++++++
>  drivers/gpu/drm/i915/intel_display.c |  50 +++
>  drivers/gpu/drm/i915/intel_drv.h     |   6 +
>  drivers/gpu/drm/i915/intel_sprite.c  |  45 ++
>  7 files changed, 1202 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> 
> -- 
> 1.9.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/11]: Color manager framework for I915 driver

[Sharma, Shashank]

Hi Daniel, 
Thanks for your time and comments. 

The current design is exactly same as we discussed previously in the mail chain, color manager is just the framework which does this job: 
1.  Create a DRM property for requesting object. 
2.   Attach the DRM property with the object. 

There is no other job done here in the framework, no parsing and nothing else. 
The color manager data structures also just add and array of DRM properties for an object (CRTC/PIPE) and total no of DRM properties. 
So there is nothing which is not required.   

Typical sequence of how it works: 
	1. intel CRTC init calls color-manager init for that CRTC, gets a color pointer, which has space to save DRM properties.
	2. intel CRTC init calls attach color properties, which will register the DRM property, add into the color pointer, and return. 
	3. A CRTC set property checks if this is color property, calls color-manager-set-property. 
	4. Color manager set-property calls core set property function, which takes care of calling platform specific set_propety function.   
	5. Color manager exit gets call from CRTC/plane destroy, and frees the DRM property per CRTC/plane, plus color pointer.

Can you please point out, which of the above steps is not falling in line for you? 

The current gamma implementation is in 8bit gamma format, which can be only used to initialize the lut, it doesn't do the gamma correction. 
The actual correction is done in 10bit gamma correction mode, which is more accurate and can support fraction level gamma correction. 

Please find the detail explanation per comment, inline. 

Regards
Shashank
-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, July 24, 2014 12:04 AM
To: Sharma, Shashank
Cc: intel-gfx@lists.freedesktop.org; ville.syrjala@linux.intel.com; Lespiau, Damien; Vetter, Daniel; Kumar, Shobhit; M, Satheeshakrishna; =indranil.mukherjee@intel.com
Subject: Re: [Intel-gfx] [PATCH 00/11]: Color manager framework for I915 driver

On Wed, Jul 23, 2014 at 11:34:54PM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> This patchset adds color-manager, a new framework in I915 driver which 
> adds color correction and tweak capabilities in the driver.
> 
> Color manager creates a DRM propery based interface for each color 
> correction, and based on the property type, registers it with each 
> CRTC/plane available.
> 
> The current implementation is for valleyview family.
> Valleyview supports following color correction properties:
> 1. CSC correction (wide gamut): This is a pipe level correction.
> There are total 9 correction coefficients in form of a 3x3 matrix, 
> which are to be programmed on 6 correction registers. CSC correction
> 
> 2. Gamma correction: This is also pipe level correction There are 
> total 256 palette registers, which can be programmed with
> 128 correction values, in 10.6 (10bit) format. The expected color 
> Correction can be applied using 129, 64 bit correction values.
> First 128 correction values are to program palette, 129th value is for 
> GCMAX register value.
> correction format in a 64 bit value is: 
> | <16 higher bits>| <16bit R value>|<16 bit G value>|<16 bit B value>|
> 
> 3. Contrast: This is sprite plane level correction Expected correction 
> value is 9 bit value Driver expects values in this format:
> |bits 64:32 | bits 31:9 | 8:0 contrast correction value|
> 
> 4. Brightness: This is also a sprite level correction Expected 
> correction value is 8 bit value Driver expects values in this format:
> |bits 64:32 | bits 31:8 | 7:0 9 bit brightness correction value|
> 
> 5. Hue and saturation: This is also a sprite level correction Expected 
> correction value is 32 bit value Driver expects values in this format:
> |bits 64:32| bits 31:0 hs correction value|
> 
> Patches:
> 1. First three patches create the basic framework.
> 2. Next 4 add functions to do color correction per property.
> 3. Next 2 add interface to set property.
> 4. last 2 patches plug-in init and exit in modeset sequences.
> 
> Shashank Sharma (11):
>   drm/i915: Color manager framework for valleyview
>   drm/i915: Register pipe level color properties
>   drm/i915: Register plane level color properties

So you're now using drm properties instead of a private ioctl, which is good. But there's still this entire indirection through the color manager and I don't understand it at all and what it serves us. From what I can see it only makes the code more complex. The basic drm approach for properties is

- Create the property once per device. If we standardize it, then it
  should be created in drm_device->mode_config, otherwise at a suitable
  place in our driver private structure.

- Link up that property with the right kms objects in the relevant init
  functions. That needs a pointer on each object to store that
  association.

- Match for these properties in the set_prop callback.

Please explain why is not sufficient with this basic&straightforward approach and what the color manager adds in value to this. Thus far I think we can just rip out the color manager without loss of functionality.

Shashank: This is exactly what we are doing in color manager, no extra work at all. 
Please note that CSC and Gamma can be only supported on PIPE, so has to be a CRTC property. 
Hue, Brightness, Contrast are only applicable for sprite planes, so it has to be Plane property. 
All we have done is, create an array of such properties, segregate it in PIPE and Plane basis, and register with every pipe/plane during init time. 

The reason why this is in a new file is: 
	1.  We don't want to over populate the 12k lines file intel_display.c
	2.  This file has a huge scope to expand, as we are going to support all the gen devices, plugging in their SOC specific color correction. For example, the 
	      Gamma correction method is different for VLV and other devices. We will sooner add another function for those devices, and just plug-in that
	      under a if check, say if (device_X), call this function. So we want all color corrections in a separate place, which makes sense to us. 

>   drm/i915: Add color manager CSC correction
>   drm/i915: Add color manager gamma correction

We already have gamma support in core drm, so we shouldn't duplicate things. There's a few things we need to do though:
- Convert gamma to be a property from the special-purpose ioctl it is
  currently.
- Add an enum property with all the gamma table formats support. Default
  would be the 256 entry 8 bit table.
- Add new table layout for vlv.
- Implement the new layout and switch between high-res and legacy gamma
  table appropriately.

Shashank: As I mentioned, there are many reasons to do this.
1.  Existing gamma correction is for 8 bit gamma correction only, which can be utilized to initialize the LUT, not to apply gamma correction. 
      For accurate gamma correction, we need 10bit/12 bit gamma corrections, based on availability of platform. 
2.  Existing gamma interface expects 256 8bit correction values per channel, whereas 10bit and 12 bit gamma correction need 16 bits (10 integer and 6 fraction bits) or  more.
      The programming method of palette registers is also totally different, which expects values in an even:odd register configuration , writing 2 registers per gamma values.
      So these two are totally different in all possible ways, and IMHO we should deprecate the previous IOCTL interface, or should just use it for LUT initialization. It doesn't do gamma
      correction. 

Note that the gamma table should be flexible enough to also support the high-res gamma tables on big cores. Or any other gpu fwiw.
Shashank: The current color manager implementation takes care of that already. Right now, in gen_6_color_correction_properties, we are giving a table which is suitable for VLV based HW. 
	We can always add a GEN_X_color_correction_properties, with different no of gamma palette entries (1024), and pick that based on GEN basis. This can't be don't in the existing IOCTL. 
 
>   drm/i915: Add contrast and brightness correction
>   drm/i915: Add hue and saturation correction
These 4 properties should imo all be drm core properties registered in drm_device->mode_config, with a setup function for all four.
Also the commit message still talk about the old design where you split up a 64 bit value. That's highly confusing. And all the indirection needs to be ripped out (see my above comment about the color manager).

Shashank: On VLV, 2 of these properties (CSC and GAMMA) can be supported on PIPE level, and rest 3 (HS, Contrast and Brightness) are only on Sprite level, they can't be applied on the PIPE level. 
So all of them can't be classified the same. Hence, we are having CSC and Gamma on CRTC and, and other three on Plane. 
Plus, this might not be true for all SOCs, and they can show different levels of color properties. In the current  design, all you have to do is list all your PIPE leve properties at one place, and that will be registered with CRTC
and plane level properties at other place, which will automatically be registered as Plane property. 

Finally we already have a few sprite properties exposed as ioctls on vlv.
I'd like those to be converted to real properties as part of this work if possible.
Shashank: Can you please elaborate what do you mean by real property ?

For a suitable merge stragety I think it would be good to split up this work into different parts:
- Convert existing ioctl properties.
- Gamma table improvements.
Shashank: This already is taken care in the current architecture. 

- Color adjustements (brightness, contrast, hue, saturation).
- CSC.

Cheers, Daniel

>   drm/i915: Add CRTC set property functions
>   drm/i915: Add set plane property functions
>   drm/i915: Plug-in color manager init
>   drm/i915: Plug-in color manager exit
> 
>  drivers/gpu/drm/i915/Makefile        |   3 +-
>  drivers/gpu/drm/i915/i915_reg.h      |  22 +
>  drivers/gpu/drm/i915/intel_clrmgr.c  | 795 
> +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_clrmgr.h  | 282 +++++++++++++  
> drivers/gpu/drm/i915/intel_display.c |  50 +++
>  drivers/gpu/drm/i915/intel_drv.h     |   6 +
>  drivers/gpu/drm/i915/intel_sprite.c  |  45 ++
>  7 files changed, 1202 insertions(+), 1 deletion(-)  create mode 
> 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> 
> --
> 1.9.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/11]: Color manager framework for I915 driver

[Matt Roper]

On Thu, Jul 24, 2014 at 04:08:41AM +0000, Sharma, Shashank wrote:
> Hi Daniel, 
> Thanks for your time and comments. 
> 
> The current design is exactly same as we discussed previously in the mail chain, color manager is just the framework which does this job: 
> 1.  Create a DRM property for requesting object. 
> 2.   Attach the DRM property with the object. 

I didn't see Daniel's response when I sent my other message, but I had a
lot of the same thoughts that he brought up.  I think my previous email
explains one of the concerns here --- properties don't hold values, so
you only need to create a property once total (well, technically once
per DRM device), not once per object.

Once you stop creating duplicate properties, you don't really need the
color manager framework at all.  Just find an appropriate driver init
function and create each property once, storing the property pointer
somewhere in dev_priv (or, if these properties can become cross-driver
standard properties, they'd be created once by the DRM core and stored
in drm_device).

> There is no other job done here in the framework, no parsing and nothing else. 
> The color manager data structures also just add and array of DRM properties for an object (CRTC/PIPE) and total no of DRM properties. 
> So there is nothing which is not required.   
> 
> Typical sequence of how it works: 
> 	1. intel CRTC init calls color-manager init for that CRTC, gets a color pointer, which has space to save DRM properties.
> 	2. intel CRTC init calls attach color properties, which will register the DRM property, add into the color pointer, and return. 

CRTC init can just attach the (already created as described above)
properties to the new CRTC being created.  No special color manager
interface calls needed.

> 	3. A CRTC set property checks if this is color property, calls color-manager-set-property. 
> 	4. Color manager set-property calls core set property function, which takes care of calling platform specific set_propety function.   

This level of indirection seems unnecessary.
intel_{crtc,plane}->set_property() can just point at functions that just
do:

        if (property == dev_priv->foo_property) {
                // do foo stuff;
        } else if (property == dev_priv->bar_property) {
                // do bar stuff;
        } else if (property == dev_priv->baz_property) {
                // do baz stuff;
        } ...

The properties you're adding now as part of the "color manager" will
likely be joined by other, unrelated propeties in the future.  There's
no need to isolate "color manager" properties behind another level of
function pointer abstraction.

> 	5. Color manager exit gets call from CRTC/plane destroy, and frees the DRM property per CRTC/plane, plus color pointer.

As with init, these can just be moved to the proper crtc/plane tear down
functions; no need to pull them out into separate color manager
functions.

> Can you please point out, which of the above steps is not falling in line for you? 

I think Daniel's big point is that the i915 driver has (or will
eventually have) lots of crtc and plane properties that do various
things.  You're pulling some of those properties out into a separate
framework that you call "color manager" that simply adds indirection.
But that extra indirection doesn't really add any value; the DRM core,
with its property support, is already all the framework we need.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 00/11]: Color manager framework for I915 driver

[Sharma, Shashank]

Thanks for your time, and review comments Matt.

I appreciate the suggestions by you, Daniel.
But I need a few more details, and I have a few concerns with the design 
you suggest, please find my comments inline.

Regards
Shashank
On 7/25/2014 6:13 AM, Matt Roper wrote:
> On Thu, Jul 24, 2014 at 04:08:41AM +0000, Sharma, Shashank wrote:
>> Hi Daniel,
>> Thanks for your time and comments.
>>
>> The current design is exactly same as we discussed previously in the mail chain, color manager is just the framework which does this job:
>> 1.  Create a DRM property for requesting object.
>> 2.   Attach the DRM property with the object.
>
> I didn't see Daniel's response when I sent my other message, but I had a
> lot of the same thoughts that he brought up.  I think my previous email
> explains one of the concerns here --- properties don't hold values, so
> you only need to create a property once total (well, technically once
> per DRM device), not once per object.
>
> Once you stop creating duplicate properties, you don't really need the
> color manager framework at all.  Just find an appropriate driver init
> function and create each property once, storing the property pointer
> somewhere in dev_priv (or, if these properties can become cross-driver
> standard properties, they'd be created once by the DRM core and stored
> in drm_device).
>
Matt, do you suggest to create one DRM property named CSC for all pipes 
? And one drm property named Gamma for all pipes ?
Can you please elaborate a bit more in this part: "Create a DRM property 
and attach to ech CRTC, managing their own values."

In this design the current design, I have few concerns here, on your 
suggestion:
1. If I enable gamma correction on one pipe (pipe A, driving DSI 
display) but don't apply gamma correction on other (pipe B, driving 
HDMI), how to maintain the state of each, without adding additional 
complexity in the driver. I have to create some additional data 
structure and attach to dev_priv.

2. The previously applied values are to be stored somewhere, to be 
re-stored in case of suspend/resume.

Plus, If I create a core DRM property for each of the color corrections, 
not all HWs running DRM driver will have properties like CSC, Gamma, Hue 
and Saturation, Contrast, Brightness. It would be a waste for them to 
have this.
>> There is no other job done here in the framework, no parsing and nothing else.
>> The color manager data structures also just add and array of DRM properties for an object (CRTC/PIPE) and total no of DRM properties.
>> So there is nothing which is not required.
>>
>> Typical sequence of how it works:
>> 	1. intel CRTC init calls color-manager init for that CRTC, gets a color pointer, which has space to save DRM properties.
>> 	2. intel CRTC init calls attach color properties, which will register the DRM property, add into the color pointer, and return.
>
> CRTC init can just attach the (already created as described above)
> properties to the new CRTC being created.  No special color manager
> interface calls needed.
>
>> 	3. A CRTC set property checks if this is color property, calls color-manager-set-property.
>> 	4. Color manager set-property calls core set property function, which takes care of calling platform specific set_propety function.
>
> This level of indirection seems unnecessary.
> intel_{crtc,plane}->set_property() can just point at functions that just
> do:
>
>          if (property == dev_priv->foo_property) {
>                  // do foo stuff;
>          } else if (property == dev_priv->bar_property) {
>                  // do bar stuff;
>          } else if (property == dev_priv->baz_property) {
>                  // do baz stuff;
>          } ...
>
> The properties you're adding now as part of the "color manager" will
> likely be joined by other, unrelated propeties in the future.  There's
> no need to isolate "color manager" properties behind another level of
> function pointer abstraction.
>
The main problems I see here is:
1. drm property doesn't hold a space to have a .set_property callback, 
so we have to hardcode this every time, based on the platform and 
property. For example, Gamma correction method in VLV and big core is 
entirely different. Some platfroms might not even support 
gamma_corerction, but some might support advance gamma_corerction.

2. If I have 10 properties, I keep on populating dev_priv with 10 
pointers, for each property, and end up writing a lot of if (property == 
dev_priv->some_property), do something.
Seeing the increase of no of DRM properties, this doesn't look good.

3. every time there is a new platform or there is a new color property 
added, I have to modify these places intel_crtc_set_property, 
intel_plane_set_property, and  add/remove one if condition.

Now, if we use color-manager, it would provide solutions for them in 
this way (also explains the need of color-manager data structures):

1. add a container data structure name color_property, which just holds 
a drm_property*, a bool status (to show if this current property is 
enabled/ adjusted /corrected or not), and the .set_property function to 
route it to appropriate set_property method.
struct clrmgr_property {
	bool enabled;
	struct drm_property *property;
	.set_handler();
}

2. Add only one pointer in dev_priv OR intel_crtc OR intel_plane
named "color_status", which is an array of all registered color 
properties with this drm_object, and a simple count of how many of them.
intel_crtc->color_status = color_manager_init();
struct clrmgr_status {
	uint count;
	struct color_property cp[max_allowed];
}

3. In case of a new platform / SOC, with different color correction 
properties, all I have to do is add an array for this platform in 
color_manager.c, like gen6_color_properties.
The color_manager_regsiter_pipe/plane function is written in such a way 
that, it will take care of everything automatically. No need to modify 
code anywhere else.

struct clrmgr_property gen_x_color_properties = {
	{"csc", no_of_values, .set_prop},
	{"gamma", no_of_values, .set_prop},
	{"X", no_of_values, .set_prop},
	{"Y", no_of_values, .set_prop}
}

struct clrmgr_property gen_y_color_properties = {
	{"csc", no_of_values, .set_prop},
	{"A", no_of_values, .set_prop},
	{"B", no_of_values, .set_prop}
}

color_property_regsiter_function
{
	/ * take out color properties as per gen (Even this can be 	
	automated using proper indexing), and create
	drm properties in a loop.*/
	while (arra_size(gen_x_color_prop)) {
		/* extract_color_properties_from_array and create DRM 	
		properties one by one */
	}
}

Now, a simple crtc_set_property/plane_set_property function will do 
this: crtc_set_property:
	struct clrmgr_status status = intel_crtc->_color_status;
	while (count < status->no_of_prop) {
		if (prop == status->cp[count]->property)
			.set_handler();
	}

>> 	5. Color manager exit gets call from CRTC/plane destroy, and frees the DRM property per CRTC/plane, plus color pointer.
>
> As with init, these can just be moved to the proper crtc/plane tear down
> functions; no need to pull them out into separate color manager
> functions.
>
>> Can you please point out, which of the above steps is not falling in line for you?
>
> I think Daniel's big point is that the i915 driver has (or will
> eventually have) lots of crtc and plane properties that do various
> things.  You're pulling some of those properties out into a separate
> framework that you call "color manager" that simply adds indirection.
> But that extra indirection doesn't really add any value; the DRM core,
> with its property support, is already all the framework we need.
>
>
> Matt
>
Yes, in fact I a agree with Daniel and you, on this point. And ideally I 
feel that all the properties(color, non-color) should follow this same 
approach to register/unregister, and we will all be spared from changing 
the code every time, and with a lot of un-necessary pointers in dev_private.
But I thought it was too ambitious to expect a change in all the 
drm_properies, so I though of starting from similar properties, from a 
domain, which is color-correction. If you guys like the approach, we can 
think of registering all the properties in this way.

Please let me know about this approach.

Re: [PATCH 00/11]: Color manager framework for I915 driver

[Matt Roper]

On Fri, Jul 25, 2014 at 10:06:27AM +0530, Sharma, Shashank wrote:
> Thanks for your time, and review comments Matt.
> 
> I appreciate the suggestions by you, Daniel.
> But I need a few more details, and I have a few concerns with the
> design you suggest, please find my comments inline.
> 
> Regards
> Shashank
> On 7/25/2014 6:13 AM, Matt Roper wrote:
> >On Thu, Jul 24, 2014 at 04:08:41AM +0000, Sharma, Shashank wrote:
> >>Hi Daniel,
> >>Thanks for your time and comments.
> >>
> >>The current design is exactly same as we discussed previously in the mail chain, color manager is just the framework which does this job:
> >>1.  Create a DRM property for requesting object.
> >>2.   Attach the DRM property with the object.
> >
> >I didn't see Daniel's response when I sent my other message, but I had a
> >lot of the same thoughts that he brought up.  I think my previous email
> >explains one of the concerns here --- properties don't hold values, so
> >you only need to create a property once total (well, technically once
> >per DRM device), not once per object.
> >
> >Once you stop creating duplicate properties, you don't really need the
> >color manager framework at all.  Just find an appropriate driver init
> >function and create each property once, storing the property pointer
> >somewhere in dev_priv (or, if these properties can become cross-driver
> >standard properties, they'd be created once by the DRM core and stored
> >in drm_device).
> >
> Matt, do you suggest to create one DRM property named CSC for all
> pipes ? And one drm property named Gamma for all pipes ?

Yep, that's what I meant.

> Can you please elaborate a bit more in this part: "Create a DRM
> property and attach to ech CRTC, managing their own values."
> 
> In this design the current design, I have few concerns here, on your
> suggestion:
> 1. If I enable gamma correction on one pipe (pipe A, driving DSI
> display) but don't apply gamma correction on other (pipe B, driving
> HDMI), how to maintain the state of each, without adding additional
> complexity in the driver. I have to create some additional data
> structure and attach to dev_priv.

The property stuff can be pretty confusing at first glance since it
doesn't quite work like a lot of people intuitively expect it to ---
when you set a property value, that value gets stored with the object
itself, not with the property.  I think it's actually a little bit
easier to understand if you dig through the DRM object data structures.
Note that drm_crtc/drm_plane/drm_connector are all derived from
drm_mode_object (using C-style inheritance).  And drm_mode_object
contains a field

        struct drm_object_properties *properties;

The definition of drm_object_properties is:

        struct drm_object_properties {
                int count;
                uint32_t ids[DRM_OBJECT_MAX_PROPERTY];
                uint64_t values[DRM_OBJECT_MAX_PROPERTY];
        };

so you can see that each object (crtc, plane, connector) has a table of
property ID's and values inside of it.

When you call one of the drm_property_create functions, the important
thing that happens is an ID number gets assigned to the new property you
created.  Then you can go attach that single property to as many other
objects (planes, crtc's, connectors) as you want.  The
drm_object_attach_property() function just adds a new entry to the ids[]
and values[] arrays shown above for the specific object.

So for example, let's assume that you modified your patch to only create
a single gamma property, as we described.  And for the purposes of this
example, let's pretend that when your code actually runs, gamma happens
to get assigned an ID number 7 by the DRM core code.  You would then
proceed to attach that gamma property to both of your BayTrail CRTC's.
After doing so, there would be some values i and j such that
        crtc1->base.properties->ids[i] == 7
        crtc2->base.properties->ids[j] == 7
In this case, your two gamma values for the two CRTC's would be stored
internally in
        crtc1->base.properties->values[i]
                and
        crtc2->base.properties->values[j]
and can be updated independently.

(Note that there are some patches on the dri-devel mailing list from Rob
Clark that refactor some of the internal structures described above in
preparation for atomic modeset, but the general idea remains the same.)

> 
> 2. The previously applied values are to be stored somewhere, to be
> re-stored in case of suspend/resume.

Right, the values that you apply get stored in each CRTC itself as

        crtc->base.properties->values[i]

If you need to get the value back again later in your driver code, you
can retrieve the value for a property associated with a specific CRTC
with the drm_object_property_get_value() function.

> 
> Plus, If I create a core DRM property for each of the color
> corrections, not all HWs running DRM driver will have properties
> like CSC, Gamma, Hue and Saturation, Contrast, Brightness. It would
> be a waste for them to have this.

True, not all hardware may support all properties.  I don't personally
know enough about color correction on non-Intel platforms to know
whether your specific properties here make sense for general
standardization or not.  For items that do apply to all hardware, see
drm_mode_create_standard_plane_properties and
drm_mode_create_standard_connector_properties for examples of how/where
we create the properties and stick them in the drm_device.  If a
property is general enough to make sense cross-driver, but may not apply
to all platforms supported by a driver or all crtc's/planes, then you
can add some additional logic to decide whether you want to attach it to
a given crtc or not.

...snip...
> >This level of indirection seems unnecessary.
> >intel_{crtc,plane}->set_property() can just point at functions that just
> >do:
> >
> >         if (property == dev_priv->foo_property) {
> >                 // do foo stuff;
> >         } else if (property == dev_priv->bar_property) {
> >                 // do bar stuff;
> >         } else if (property == dev_priv->baz_property) {
> >                 // do baz stuff;
> >         } ...
> >
> >The properties you're adding now as part of the "color manager" will
> >likely be joined by other, unrelated propeties in the future.  There's
> >no need to isolate "color manager" properties behind another level of
> >function pointer abstraction.
> >
> The main problems I see here is:
> 1. drm property doesn't hold a space to have a .set_property
> callback, so we have to hardcode this every time, based on the
> platform and property. For example, Gamma correction method in VLV
> and big core is entirely different. Some platfroms might not even
> support gamma_corerction, but some might support advance
> gamma_corerction.

The i915 driver already sort of has a pattern that gets used when you
have a generic driver entrypoint that needs to eventually dispatch to
platform-specific logic.  If you look in intel_display.c, there's a
function intel_init_display() that looks at your device ID and then sets
up some platform-specific function pointers.  So you might add a new
dev_priv->display.set_gamma field and hook up appropriate
vlv_set_gamma(), hsw_set_gamma(), i9xx_set_gamma(), etc. implementations
for whatever platforms you're exposing the property on.  Then your main
intel_crtc->set_property() function that I gave pseudocode for above
could become more like:

         if (property == dev_priv->gamma_property) {
                 dev_priv->display.set_gamma(crtc);
         } else if (property == dev_priv->csc_property) {
                 dev_priv->display.set_csc(crtc);
         } ...

> 2. If I have 10 properties, I keep on populating dev_priv with 10
> pointers, for each property, and end up writing a lot of if
> (property == dev_priv->some_property), do something.
> Seeing the increase of no of DRM properties, this doesn't look good.

I don't see that as too much of a problem since, as I showed above,
you're probably not actually going to put the entire implementation
directly in the main set_plane handler, but rather call off to
platform-specific calls.  So there might be a lot of properties as time
goes on, but the code still stays fairly compact and easy to read.  The
main difference from your initial code is that the platform-specific
functions are following the same model that's already used in the driver
for other things like crtc enable/disable, setplane, modeset, etc.
rather than using a new layer of indirection that works a bit
differently.

> 3. every time there is a new platform or there is a new color
> property added, I have to modify these places
> intel_crtc_set_property, intel_plane_set_property, and  add/remove
> one if condition.

As I noted above, the platform-specific dev_priv->display dispatch table
helps with this.  It should provide the same form of separation /
abstraction that you were shooting for with your color manager code,
just in a manner that's a little bit more in line with how other parts
of i915 already work.

I think the above explanations should also cover the points you list
below, but if you still have concerns or questions about any of them,
feel free to ask.


Matt

> 
> Now, if we use color-manager, it would provide solutions for them in
> this way (also explains the need of color-manager data structures):
> 
> 1. add a container data structure name color_property, which just
> holds a drm_property*, a bool status (to show if this current
> property is enabled/ adjusted /corrected or not), and the
> .set_property function to route it to appropriate set_property
> method.
> struct clrmgr_property {
> 	bool enabled;
> 	struct drm_property *property;
> 	.set_handler();
> }
> 
> 2. Add only one pointer in dev_priv OR intel_crtc OR intel_plane
> named "color_status", which is an array of all registered color
> properties with this drm_object, and a simple count of how many of
> them.
> intel_crtc->color_status = color_manager_init();
> struct clrmgr_status {
> 	uint count;
> 	struct color_property cp[max_allowed];
> }
> 
> 3. In case of a new platform / SOC, with different color correction
> properties, all I have to do is add an array for this platform in
> color_manager.c, like gen6_color_properties.
> The color_manager_regsiter_pipe/plane function is written in such a
> way that, it will take care of everything automatically. No need to
> modify code anywhere else.
> 
> struct clrmgr_property gen_x_color_properties = {
> 	{"csc", no_of_values, .set_prop},
> 	{"gamma", no_of_values, .set_prop},
> 	{"X", no_of_values, .set_prop},
> 	{"Y", no_of_values, .set_prop}
> }
> 
> struct clrmgr_property gen_y_color_properties = {
> 	{"csc", no_of_values, .set_prop},
> 	{"A", no_of_values, .set_prop},
> 	{"B", no_of_values, .set_prop}
> }
> 
> color_property_regsiter_function
> {
> 	/ * take out color properties as per gen (Even this can be 	
> 	automated using proper indexing), and create
> 	drm properties in a loop.*/
> 	while (arra_size(gen_x_color_prop)) {
> 		/* extract_color_properties_from_array and create DRM 	
> 		properties one by one */
> 	}
> }
> 
> Now, a simple crtc_set_property/plane_set_property function will do
> this: crtc_set_property:
> 	struct clrmgr_status status = intel_crtc->_color_status;
> 	while (count < status->no_of_prop) {
> 		if (prop == status->cp[count]->property)
> 			.set_handler();
> 	}
> 
> >>	5. Color manager exit gets call from CRTC/plane destroy, and frees the DRM property per CRTC/plane, plus color pointer.
> >
> >As with init, these can just be moved to the proper crtc/plane tear down
> >functions; no need to pull them out into separate color manager
> >functions.
> >
> >>Can you please point out, which of the above steps is not falling in line for you?
> >
> >I think Daniel's big point is that the i915 driver has (or will
> >eventually have) lots of crtc and plane properties that do various
> >things.  You're pulling some of those properties out into a separate
> >framework that you call "color manager" that simply adds indirection.
> >But that extra indirection doesn't really add any value; the DRM core,
> >with its property support, is already all the framework we need.
> >
> >
> >Matt
> >
> Yes, in fact I a agree with Daniel and you, on this point. And
> ideally I feel that all the properties(color, non-color) should
> follow this same approach to register/unregister, and we will all be
> spared from changing the code every time, and with a lot of
> un-necessary pointers in dev_private.
> But I thought it was too ambitious to expect a change in all the
> drm_properies, so I though of starting from similar properties, from
> a domain, which is color-correction. If you guys like the approach,
> we can think of registering all the properties in this way.
> 
> Please let me know about this approach.

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 00/11]: Color manager framework for I915 driver

[Sharma, Shashank]

Thanks a lot for your time and the detailed explanation, Matt. 
I will re-design the patches according to your / Daniel's suggestions. 

Regards
Shashank
-----Original Message-----
From: Roper, Matthew D 
Sent: Saturday, July 26, 2014 7:29 AM
To: Sharma, Shashank
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Vetter, Daniel
Subject: Re: [Intel-gfx] [PATCH 00/11]: Color manager framework for I915 driver

On Fri, Jul 25, 2014 at 10:06:27AM +0530, Sharma, Shashank wrote:
> Thanks for your time, and review comments Matt.
> 
> I appreciate the suggestions by you, Daniel.
> But I need a few more details, and I have a few concerns with the 
> design you suggest, please find my comments inline.
> 
> Regards
> Shashank
> On 7/25/2014 6:13 AM, Matt Roper wrote:
> >On Thu, Jul 24, 2014 at 04:08:41AM +0000, Sharma, Shashank wrote:
> >>Hi Daniel,
> >>Thanks for your time and comments.
> >>
> >>The current design is exactly same as we discussed previously in the mail chain, color manager is just the framework which does this job:
> >>1.  Create a DRM property for requesting object.
> >>2.   Attach the DRM property with the object.
> >
> >I didn't see Daniel's response when I sent my other message, but I 
> >had a lot of the same thoughts that he brought up.  I think my 
> >previous email explains one of the concerns here --- properties don't 
> >hold values, so you only need to create a property once total (well, 
> >technically once per DRM device), not once per object.
> >
> >Once you stop creating duplicate properties, you don't really need 
> >the color manager framework at all.  Just find an appropriate driver 
> >init function and create each property once, storing the property 
> >pointer somewhere in dev_priv (or, if these properties can become 
> >cross-driver standard properties, they'd be created once by the DRM 
> >core and stored in drm_device).
> >
> Matt, do you suggest to create one DRM property named CSC for all 
> pipes ? And one drm property named Gamma for all pipes ?

Yep, that's what I meant.

> Can you please elaborate a bit more in this part: "Create a DRM 
> property and attach to ech CRTC, managing their own values."
> 
> In this design the current design, I have few concerns here, on your
> suggestion:
> 1. If I enable gamma correction on one pipe (pipe A, driving DSI
> display) but don't apply gamma correction on other (pipe B, driving 
> HDMI), how to maintain the state of each, without adding additional 
> complexity in the driver. I have to create some additional data 
> structure and attach to dev_priv.

The property stuff can be pretty confusing at first glance since it doesn't quite work like a lot of people intuitively expect it to --- when you set a property value, that value gets stored with the object itself, not with the property.  I think it's actually a little bit easier to understand if you dig through the DRM object data structures.
Note that drm_crtc/drm_plane/drm_connector are all derived from drm_mode_object (using C-style inheritance).  And drm_mode_object contains a field

        struct drm_object_properties *properties;

The definition of drm_object_properties is:

        struct drm_object_properties {
                int count;
                uint32_t ids[DRM_OBJECT_MAX_PROPERTY];
                uint64_t values[DRM_OBJECT_MAX_PROPERTY];
        };

so you can see that each object (crtc, plane, connector) has a table of property ID's and values inside of it.

When you call one of the drm_property_create functions, the important thing that happens is an ID number gets assigned to the new property you created.  Then you can go attach that single property to as many other objects (planes, crtc's, connectors) as you want.  The
drm_object_attach_property() function just adds a new entry to the ids[] and values[] arrays shown above for the specific object.

So for example, let's assume that you modified your patch to only create a single gamma property, as we described.  And for the purposes of this example, let's pretend that when your code actually runs, gamma happens to get assigned an ID number 7 by the DRM core code.  You would then proceed to attach that gamma property to both of your BayTrail CRTC's.
After doing so, there would be some values i and j such that
        crtc1->base.properties->ids[i] == 7
        crtc2->base.properties->ids[j] == 7 In this case, your two gamma values for the two CRTC's would be stored internally in
        crtc1->base.properties->values[i]
                and
        crtc2->base.properties->values[j] and can be updated independently.

(Note that there are some patches on the dri-devel mailing list from Rob Clark that refactor some of the internal structures described above in preparation for atomic modeset, but the general idea remains the same.)

> 
> 2. The previously applied values are to be stored somewhere, to be 
> re-stored in case of suspend/resume.

Right, the values that you apply get stored in each CRTC itself as

        crtc->base.properties->values[i]

If you need to get the value back again later in your driver code, you can retrieve the value for a property associated with a specific CRTC with the drm_object_property_get_value() function.

> 
> Plus, If I create a core DRM property for each of the color 
> corrections, not all HWs running DRM driver will have properties like 
> CSC, Gamma, Hue and Saturation, Contrast, Brightness. It would be a 
> waste for them to have this.

True, not all hardware may support all properties.  I don't personally know enough about color correction on non-Intel platforms to know whether your specific properties here make sense for general standardization or not.  For items that do apply to all hardware, see drm_mode_create_standard_plane_properties and drm_mode_create_standard_connector_properties for examples of how/where we create the properties and stick them in the drm_device.  If a property is general enough to make sense cross-driver, but may not apply to all platforms supported by a driver or all crtc's/planes, then you can add some additional logic to decide whether you want to attach it to a given crtc or not.

...snip...
> >This level of indirection seems unnecessary.
> >intel_{crtc,plane}->set_property() can just point at functions that 
> >just
> >do:
> >
> >         if (property == dev_priv->foo_property) {
> >                 // do foo stuff;
> >         } else if (property == dev_priv->bar_property) {
> >                 // do bar stuff;
> >         } else if (property == dev_priv->baz_property) {
> >                 // do baz stuff;
> >         } ...
> >
> >The properties you're adding now as part of the "color manager" will 
> >likely be joined by other, unrelated propeties in the future.  
> >There's no need to isolate "color manager" properties behind another 
> >level of function pointer abstraction.
> >
> The main problems I see here is:
> 1. drm property doesn't hold a space to have a .set_property callback, 
> so we have to hardcode this every time, based on the platform and 
> property. For example, Gamma correction method in VLV and big core is 
> entirely different. Some platfroms might not even support 
> gamma_corerction, but some might support advance gamma_corerction.

The i915 driver already sort of has a pattern that gets used when you have a generic driver entrypoint that needs to eventually dispatch to platform-specific logic.  If you look in intel_display.c, there's a function intel_init_display() that looks at your device ID and then sets up some platform-specific function pointers.  So you might add a new dev_priv->display.set_gamma field and hook up appropriate vlv_set_gamma(), hsw_set_gamma(), i9xx_set_gamma(), etc. implementations for whatever platforms you're exposing the property on.  Then your main
intel_crtc->set_property() function that I gave pseudocode for above could become more like:

         if (property == dev_priv->gamma_property) {
                 dev_priv->display.set_gamma(crtc);
         } else if (property == dev_priv->csc_property) {
                 dev_priv->display.set_csc(crtc);
         } ...

> 2. If I have 10 properties, I keep on populating dev_priv with 10 
> pointers, for each property, and end up writing a lot of if (property 
> == dev_priv->some_property), do something.
> Seeing the increase of no of DRM properties, this doesn't look good.

I don't see that as too much of a problem since, as I showed above, you're probably not actually going to put the entire implementation directly in the main set_plane handler, but rather call off to platform-specific calls.  So there might be a lot of properties as time goes on, but the code still stays fairly compact and easy to read.  The main difference from your initial code is that the platform-specific functions are following the same model that's already used in the driver for other things like crtc enable/disable, setplane, modeset, etc.
rather than using a new layer of indirection that works a bit differently.

> 3. every time there is a new platform or there is a new color property 
> added, I have to modify these places intel_crtc_set_property, 
> intel_plane_set_property, and  add/remove one if condition.

As I noted above, the platform-specific dev_priv->display dispatch table helps with this.  It should provide the same form of separation / abstraction that you were shooting for with your color manager code, just in a manner that's a little bit more in line with how other parts of i915 already work.

I think the above explanations should also cover the points you list below, but if you still have concerns or questions about any of them, feel free to ask.


Matt

> 
> Now, if we use color-manager, it would provide solutions for them in 
> this way (also explains the need of color-manager data structures):
> 
> 1. add a container data structure name color_property, which just 
> holds a drm_property*, a bool status (to show if this current property 
> is enabled/ adjusted /corrected or not), and the .set_property 
> function to route it to appropriate set_property method.
> struct clrmgr_property {
> 	bool enabled;
> 	struct drm_property *property;
> 	.set_handler();
> }
> 
> 2. Add only one pointer in dev_priv OR intel_crtc OR intel_plane named 
> "color_status", which is an array of all registered color properties 
> with this drm_object, and a simple count of how many of them.
> intel_crtc->color_status = color_manager_init(); struct clrmgr_status 
> {
> 	uint count;
> 	struct color_property cp[max_allowed]; }
> 
> 3. In case of a new platform / SOC, with different color correction 
> properties, all I have to do is add an array for this platform in 
> color_manager.c, like gen6_color_properties.
> The color_manager_regsiter_pipe/plane function is written in such a 
> way that, it will take care of everything automatically. No need to 
> modify code anywhere else.
> 
> struct clrmgr_property gen_x_color_properties = {
> 	{"csc", no_of_values, .set_prop},
> 	{"gamma", no_of_values, .set_prop},
> 	{"X", no_of_values, .set_prop},
> 	{"Y", no_of_values, .set_prop}
> }
> 
> struct clrmgr_property gen_y_color_properties = {
> 	{"csc", no_of_values, .set_prop},
> 	{"A", no_of_values, .set_prop},
> 	{"B", no_of_values, .set_prop}
> }
> 
> color_property_regsiter_function
> {
> 	/ * take out color properties as per gen (Even this can be 	
> 	automated using proper indexing), and create
> 	drm properties in a loop.*/
> 	while (arra_size(gen_x_color_prop)) {
> 		/* extract_color_properties_from_array and create DRM 	
> 		properties one by one */
> 	}
> }
> 
> Now, a simple crtc_set_property/plane_set_property function will do
> this: crtc_set_property:
> 	struct clrmgr_status status = intel_crtc->_color_status;
> 	while (count < status->no_of_prop) {
> 		if (prop == status->cp[count]->property)
> 			.set_handler();
> 	}
> 
> >>	5. Color manager exit gets call from CRTC/plane destroy, and frees the DRM property per CRTC/plane, plus color pointer.
> >
> >As with init, these can just be moved to the proper crtc/plane tear 
> >down functions; no need to pull them out into separate color manager 
> >functions.
> >
> >>Can you please point out, which of the above steps is not falling in line for you?
> >
> >I think Daniel's big point is that the i915 driver has (or will 
> >eventually have) lots of crtc and plane properties that do various 
> >things.  You're pulling some of those properties out into a separate 
> >framework that you call "color manager" that simply adds indirection.
> >But that extra indirection doesn't really add any value; the DRM 
> >core, with its property support, is already all the framework we need.
> >
> >
> >Matt
> >
> Yes, in fact I a agree with Daniel and you, on this point. And ideally 
> I feel that all the properties(color, non-color) should follow this 
> same approach to register/unregister, and we will all be spared from 
> changing the code every time, and with a lot of un-necessary pointers 
> in dev_private.
> But I thought it was too ambitious to expect a change in all the 
> drm_properies, so I though of starting from similar properties, from a 
> domain, which is color-correction. If you guys like the approach, we 
> can think of registering all the properties in this way.
> 
> Please let me know about this approach.

--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH 0/4] Color manager framework

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Color manager is an extention to i915 driver which provides display
tuning and color-correction properties to user space, via DRM propery
interface.Different Intel platforms support different color tuning capabilities
which can be exploited using this framework.

This patch set adds color correction for VLV, and the code is written
in such a way that new color properties and support for other platforms can
be pluggen in, using the same architecture.

For the design discussion, right now only one color correction property (CSC)
has been added. Once we agree on the design, gamma-correction, contrast, brightness,
and hue/saturation would be followed by the same.

What this patch set does, is:
1. Color manager framework for valleyview:
Add basic functions of framework, to create and destroy DRM properties for
color correction. It also adds header, enums and defines.

2. Plug-in color manager attach
Attach created color properties, with the objects. Basically properties get attached to
two type of objects, crtc (pipe level correction) and plane (plane level correction).

3. CSC color correction
First color correction method.
- Add color property for CSC during init. 
- Add blob to keep correction values
- Attach DRM CSC propery with each CRTC object
- Core CSC correction for VLV

4. Add set_property function for intel CRTC.
This function checks the type of the property, and calls the
appropriate high level function (intel_clrmgr_set_csc), which does
platform check and calls the core platform color correction
function (vlv_set_csc)

V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
- Creating only one property per color correction, and attaching it to every DRM object.
- No additional data structures on top of DRM property.
- No registeration of color property, just create and attach.
- Added properties in dev->mode_config

Shashank Sharma (4):
  drm/i915: Color manager framework for valleyview
  drm/i915: Plug-in color manager attach
  drm/i915: CSC color correction
  drm/i915: Add set_protpery function

 drivers/gpu/drm/drm_crtc.c           |   4 +-
 drivers/gpu/drm/i915/Makefile        |   3 +-
 drivers/gpu/drm/i915/i915_reg.h      |  11 ++
 drivers/gpu/drm/i915/intel_clrmgr.c  | 283 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h  | 108 +++++++++++++
 drivers/gpu/drm/i915/intel_display.c |  25 ++++
 drivers/gpu/drm/i915/intel_drv.h     |   1 +
 drivers/gpu/drm/i915/intel_sprite.c  |   3 +
 include/drm/drm_crtc.h               |   7 +
 9 files changed, 442 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h

-- 
1.9.1

[PATCH 1/4] drm/i915: Color manager framework for valleyview

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Color manager is a framework which adds drm properties for
color correction in I915 driver. This framework creates DRM
properties for each color correction feature, and attaches
it to appropriate CRTC/plane based on the property type.
This allows userspace to fine tune the display as per the panel.

This is the first patch of the series, what this patch does is:
1. Create 2 new files
	intel_clrmgr.c
	intel_clrmgr.h
2. Add color manager init function, This function will create
   DRM properties for color correction.
3. Add color manager exit function. This function will destroy
   registered DRM color properties.
4. Adds a enum for currently listed color correction properties:
   they are:
   CSC correction (wide gamut), Gamma correction, Contrast,
   Brightness, Hue and Saturation
   This enum will be further used to index color properties
   from array of elements.
5. Add names for vlv color properties.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/Makefile        |  3 +-
 drivers/gpu/drm/i915/intel_clrmgr.c  | 80 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_clrmgr.h  | 70 +++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_display.c |  5 +++
 4 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
 create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c1dd485..6361c9b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -46,7 +46,8 @@ i915-y += intel_bios.o \
 	  intel_modes.o \
 	  intel_overlay.o \
 	  intel_sideband.o \
-	  intel_sprite.o
+	  intel_sprite.o \
+	  intel_clrmgr.o
 i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
 i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
 
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
new file mode 100644
index 0000000..0def917
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -0,0 +1,80 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * ======
+ * Shashank Sharma <shashank.sharma@intel.com>
+ * Uma Shankar <uma.shankar@intel.com>
+ * Sonika Jindal <sonika.jindal@intel.com>
+ */
+
+#include "i915_drm.h"
+#include "i915_drv.h"
+#include "i915_reg.h"
+#include "intel_clrmgr.h"
+
+/* Names to register with color properties */
+const char *clrmgr_property_names[] = {
+	/* csc */
+	"csc-correction",
+	/* gamma */
+	"gamma-correction",
+	/* contrast */
+	"contrast",
+	/* brightness */
+	"brightness",
+	/* hue_saturation */
+	"hue_saturation"
+	/* add a new prop name here */
+};
+
+int intel_clrmgr_create_color_properties(struct drm_device *dev)
+{
+	DRM_DEBUG_DRIVER("\n");
+	return 0;
+}
+
+void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
+{
+	DRM_DEBUG_DRIVER("\n");
+}
+
+void intel_clrmgr_init(struct drm_device *dev)
+{
+	int ret;
+
+	/* Create color properties */
+	ret = intel_clrmgr_create_color_properties(dev);
+	if (ret) {
+		DRM_ERROR("Unable to create %d propert%s\n",
+			ret, ret > 1 ? "ies" : "y");
+		return;
+	}
+	DRM_DEBUG_DRIVER("Successfully created color properties\n");
+}
+
+void intel_clrmgr_exit(struct drm_device *dev)
+{
+	/* Remove color properties */
+	intel_clrmgr_destroy_color_properties(dev);
+	DRM_DEBUG_DRIVER("Destroyed color properties\n");
+}
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
new file mode 100644
index 0000000..1b7e906
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -0,0 +1,70 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * =====
+ * Shashank Sharma <shashank.sharma@intel.com>
+ * Uma Shankar <uma.shankar@intel.com>
+ * Sonika Jindal <sonika.jindal@intel.com>
+ */
+
+#ifndef _I915_CLR_MNGR_H_
+#define _I915_CLR_MNGR_H_
+
+#include "drmP.h"
+#include "intel_drv.h"
+#include <linux/errno.h>
+
+/* Framework defs */
+#define CLRMGR_PROP_MAX				10
+#define CLRMGR_PROP_NAME_MAX				128
+#define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
+
+/* Properties */
+enum clrmgr_tweaks {
+	csc = 0,
+	gamma,
+	contrast,
+	brightness,
+	hue_saturation,
+	clrmgr_tweak_invalid
+};
+
+/*
+* intel_clrmgr_init:
+* Create drm properties for color correction
+* Allocate memory to store current color correction
+* input: struct drm_device *
+*/
+void intel_clrmgr_init(struct drm_device *dev);
+
+/*
+* intel_clrmgr_exit
+* Destroy color correction DRM properties
+* Free allocated memory for color correction storage
+* Should be called from CRTC/Plane .destroy function
+* input:
+* struct drm_device *
+*/
+void intel_clrmgr_exit(struct drm_device *dev);
+
+#endif
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index e0beaad..df2dcbd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -42,6 +42,7 @@
 #include <drm/drm_plane_helper.h>
 #include <drm/drm_rect.h>
 #include <linux/dma_remapping.h>
+#include "intel_clrmgr.h"
 
 /* Primary plane formats supported by all gen */
 #define COMMON_PRIMARY_FORMATS \
@@ -12816,6 +12817,8 @@ void intel_modeset_init(struct drm_device *dev)
 		      INTEL_INFO(dev)->num_pipes,
 		      INTEL_INFO(dev)->num_pipes > 1 ? "s" : "");
 
+	intel_clrmgr_init(dev);
+
 	for_each_pipe(dev_priv, pipe) {
 		intel_crtc_init(dev, pipe);
 		for_each_sprite(pipe, sprite) {
@@ -13349,6 +13352,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
 		intel_connector->unregister(intel_connector);
 	}
 
+	intel_clrmgr_exit(dev);
+
 	drm_mode_config_cleanup(dev);
 
 	intel_cleanup_overlay(dev);
-- 
1.9.1

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

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Bob Paauwe]

On Tue, 9 Sep 2014 11:53:13 +0530
<shashank.sharma@intel.com> wrote:

> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> Color manager is a framework which adds drm properties for
> color correction in I915 driver. This framework creates DRM
> properties for each color correction feature, and attaches
> it to appropriate CRTC/plane based on the property type.
> This allows userspace to fine tune the display as per the panel.
> 
> This is the first patch of the series, what this patch does is:
> 1. Create 2 new files
> 	intel_clrmgr.c
> 	intel_clrmgr.h
> 2. Add color manager init function, This function will create
>    DRM properties for color correction.
> 3. Add color manager exit function. This function will destroy
>    registered DRM color properties.
> 4. Adds a enum for currently listed color correction properties:
>    they are:
>    CSC correction (wide gamut), Gamma correction, Contrast,
>    Brightness, Hue and Saturation
>    This enum will be further used to index color properties
>    from array of elements.
> 5. Add names for vlv color properties.

I'd suggest maybe dropping the name "color manager" and "clrmgr" in
favor of "color properties" and maybe "color props" as a shorter form.

> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> ---
>  drivers/gpu/drm/i915/Makefile        |  3 +-
>  drivers/gpu/drm/i915/intel_clrmgr.c  | 80 ++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_clrmgr.h  | 70 +++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_display.c |  5 +++
>  4 files changed, 157 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c1dd485..6361c9b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -46,7 +46,8 @@ i915-y += intel_bios.o \
>  	  intel_modes.o \
>  	  intel_overlay.o \
>  	  intel_sideband.o \
> -	  intel_sprite.o
> +	  intel_sprite.o \
> +	  intel_clrmgr.o
>  i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
>  i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
>  
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> new file mode 100644
> index 0000000..0def917
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * ======
> + * Shashank Sharma <shashank.sharma@intel.com>
> + * Uma Shankar <uma.shankar@intel.com>
> + * Sonika Jindal <sonika.jindal@intel.com>
> + */
> +
> +#include "i915_drm.h"
> +#include "i915_drv.h"
> +#include "i915_reg.h"
> +#include "intel_clrmgr.h"
> +
> +/* Names to register with color properties */
> +const char *clrmgr_property_names[] = {
> +	/* csc */
> +	"csc-correction",
> +	/* gamma */
> +	"gamma-correction",
> +	/* contrast */
> +	"contrast",
> +	/* brightness */
> +	"brightness",
> +	/* hue_saturation */
> +	"hue_saturation"
> +	/* add a new prop name here */
> +};

I don't think you need the comments for each of the names.  The names
themselves are descriptive.

I haven't looked at the rest of the series yet, but in embedded we've
considered hue and saturation separate properties.

It looks like you drop this array in the second patch.  You should
simply not introduce it at all. Oh an then you re-introduce this array
back in patch 3 but only the first part of it. 

> +
> +int intel_clrmgr_create_color_properties(struct drm_device *dev)
> +{
> +	DRM_DEBUG_DRIVER("\n");
> +	return 0;
> +}
> +
> +void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
> +{
> +	DRM_DEBUG_DRIVER("\n");
> +}

I don't really see a need for the above functions. I think just
creating the properties in the init function will simplify the code
a bit. Same for the exit and destroy functions.

> +
> +void intel_clrmgr_init(struct drm_device *dev)
> +{
> +	int ret;
> +
> +	/* Create color properties */
> +	ret = intel_clrmgr_create_color_properties(dev);
> +	if (ret) {
> +		DRM_ERROR("Unable to create %d propert%s\n",
> +			ret, ret > 1 ? "ies" : "y");
> +		return;
> +	}
> +	DRM_DEBUG_DRIVER("Successfully created color properties\n");
> +}
> +
> +void intel_clrmgr_exit(struct drm_device *dev)
> +{
> +	/* Remove color properties */
> +	intel_clrmgr_destroy_color_properties(dev);
> +	DRM_DEBUG_DRIVER("Destroyed color properties\n");
> +}

I believe the standard practice is to introduce functioning code and
not subbed functions.  It makes it easier to review if the function is
fleshed out when it's first introduced.


> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
> new file mode 100644
> index 0000000..1b7e906
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
> @@ -0,0 +1,70 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * =====
> + * Shashank Sharma <shashank.sharma@intel.com>
> + * Uma Shankar <uma.shankar@intel.com>
> + * Sonika Jindal <sonika.jindal@intel.com>
> + */
> +
> +#ifndef _I915_CLR_MNGR_H_
> +#define _I915_CLR_MNGR_H_
> +
> +#include "drmP.h"
> +#include "intel_drv.h"
> +#include <linux/errno.h>
> +
> +/* Framework defs */
> +#define CLRMGR_PROP_MAX				10
> +#define CLRMGR_PROP_NAME_MAX				128
> +#define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
> +
> +/* Properties */
> +enum clrmgr_tweaks {
> +	csc = 0,
> +	gamma,
> +	contrast,
> +	brightness,
> +	hue_saturation,
> +	clrmgr_tweak_invalid
> +};
> +
> +/*
> +* intel_clrmgr_init:
> +* Create drm properties for color correction
> +* Allocate memory to store current color correction
> +* input: struct drm_device *
> +*/
> +void intel_clrmgr_init(struct drm_device *dev);
> +
> +/*
> +* intel_clrmgr_exit
> +* Destroy color correction DRM properties
> +* Free allocated memory for color correction storage
> +* Should be called from CRTC/Plane .destroy function
> +* input:
> +* struct drm_device *
> +*/
> +void intel_clrmgr_exit(struct drm_device *dev);
> +
> +#endif
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index e0beaad..df2dcbd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -42,6 +42,7 @@
>  #include <drm/drm_plane_helper.h>
>  #include <drm/drm_rect.h>
>  #include <linux/dma_remapping.h>
> +#include "intel_clrmgr.h"
>  
>  /* Primary plane formats supported by all gen */
>  #define COMMON_PRIMARY_FORMATS \
> @@ -12816,6 +12817,8 @@ void intel_modeset_init(struct drm_device *dev)
>  		      INTEL_INFO(dev)->num_pipes,
>  		      INTEL_INFO(dev)->num_pipes > 1 ? "s" : "");
>  
> +	intel_clrmgr_init(dev);
> +
>  	for_each_pipe(dev_priv, pipe) {
>  		intel_crtc_init(dev, pipe);
>  		for_each_sprite(pipe, sprite) {
> @@ -13349,6 +13352,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>  		intel_connector->unregister(intel_connector);
>  	}
>  
> +	intel_clrmgr_exit(dev);
> +
>  	drm_mode_config_cleanup(dev);
>  
>  	intel_cleanup_overlay(dev);

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Sharma, Shashank]

Hello Bob,

Thanks for your time and review comments.
Please find my comments inline.

Regards
Shashank
On 9/10/2014 4:21 AM, Bob Paauwe wrote:
> On Tue, 9 Sep 2014 11:53:13 +0530
> <shashank.sharma@intel.com> wrote:
>
>> From: Shashank Sharma <shashank.sharma@intel.com>
>>
>> Color manager is a framework which adds drm properties for
>> color correction in I915 driver. This framework creates DRM
>> properties for each color correction feature, and attaches
>> it to appropriate CRTC/plane based on the property type.
>> This allows userspace to fine tune the display as per the panel.
>>
>> This is the first patch of the series, what this patch does is:
>> 1. Create 2 new files
>> 	intel_clrmgr.c
>> 	intel_clrmgr.h
>> 2. Add color manager init function, This function will create
>>     DRM properties for color correction.
>> 3. Add color manager exit function. This function will destroy
>>     registered DRM color properties.
>> 4. Adds a enum for currently listed color correction properties:
>>     they are:
>>     CSC correction (wide gamut), Gamma correction, Contrast,
>>     Brightness, Hue and Saturation
>>     This enum will be further used to index color properties
>>     from array of elements.
>> 5. Add names for vlv color properties.
>
> I'd suggest maybe dropping the name "color manager" and "clrmgr" in
> favor of "color properties" and maybe "color props" as a shorter form.
>
I will try to comply with this suggestion.
>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>> ---
>>   drivers/gpu/drm/i915/Makefile        |  3 +-
>>   drivers/gpu/drm/i915/intel_clrmgr.c  | 80 ++++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_clrmgr.h  | 70 +++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_display.c |  5 +++
>>   4 files changed, 157 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
>>
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index c1dd485..6361c9b 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -46,7 +46,8 @@ i915-y += intel_bios.o \
>>   	  intel_modes.o \
>>   	  intel_overlay.o \
>>   	  intel_sideband.o \
>> -	  intel_sprite.o
>> +	  intel_sprite.o \
>> +	  intel_clrmgr.o
>>   i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
>>   i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
>>
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
>> new file mode 100644
>> index 0000000..0def917
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
>> @@ -0,0 +1,80 @@
>> +/*
>> + * Copyright © 2014 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
>> + * IN THE SOFTWARE.
>> + *
>> + * Authors:
>> + * ======
>> + * Shashank Sharma <shashank.sharma@intel.com>
>> + * Uma Shankar <uma.shankar@intel.com>
>> + * Sonika Jindal <sonika.jindal@intel.com>
>> + */
>> +
>> +#include "i915_drm.h"
>> +#include "i915_drv.h"
>> +#include "i915_reg.h"
>> +#include "intel_clrmgr.h"
>> +
>> +/* Names to register with color properties */
>> +const char *clrmgr_property_names[] = {
>> +	/* csc */
>> +	"csc-correction",
>> +	/* gamma */
>> +	"gamma-correction",
>> +	/* contrast */
>> +	"contrast",
>> +	/* brightness */
>> +	"brightness",
>> +	/* hue_saturation */
>> +	"hue_saturation"
>> +	/* add a new prop name here */
>> +};
>
> I don't think you need the comments for each of the names.  The names
> themselves are descriptive.
>
> I haven't looked at the rest of the series yet, but in embedded we've
> considered hue and saturation separate properties.
>
Actually they are, but in VLV hardware they are getting 
programmed/adjusted via the same register (single), so I am force to 
combine them together.
> It looks like you drop this array in the second patch.  You should
> simply not introduce it at all. Oh an then you re-introduce this array
> back in patch 3 but only the first part of it.
>
Actually my plan was to add an empty array, and then add names, sizes 
along with the corresponding property specific patches. That made a mess.
>> +
>> +int intel_clrmgr_create_color_properties(struct drm_device *dev)
>> +{
>> +	DRM_DEBUG_DRIVER("\n");
>> +	return 0;
>> +}
>> +
>> +void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
>> +{
>> +	DRM_DEBUG_DRIVER("\n");
>> +}
>
> I don't really see a need for the above functions. I think just
> creating the properties in the init function will simplify the code
> a bit. Same for the exit and destroy functions.
>
Yes, I agree.
>> +
>> +void intel_clrmgr_init(struct drm_device *dev)
>> +{
>> +	int ret;
>> +
>> +	/* Create color properties */
>> +	ret = intel_clrmgr_create_color_properties(dev);
>> +	if (ret) {
>> +		DRM_ERROR("Unable to create %d propert%s\n",
>> +			ret, ret > 1 ? "ies" : "y");
>> +		return;
>> +	}
>> +	DRM_DEBUG_DRIVER("Successfully created color properties\n");
>> +}
>> +
>> +void intel_clrmgr_exit(struct drm_device *dev)
>> +{
>> +	/* Remove color properties */
>> +	intel_clrmgr_destroy_color_properties(dev);
>> +	DRM_DEBUG_DRIVER("Destroyed color properties\n");
>> +}
>
> I believe the standard practice is to introduce functioning code and
> not subbed functions.  It makes it easier to review if the function is
> fleshed out when it's first introduced.
>
Yes, actually my idea was to add empty functions, and populate them 
along with the corresponding property patches. For example CSC patch 
will come and populate create_properties, destroy_properties, 
attach_pipe_properties etc. But looks like this is not making it very 
clear. I will change this.
>
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
>> new file mode 100644
>> index 0000000..1b7e906
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
>> @@ -0,0 +1,70 @@
>> +/*
>> + * Copyright © 2014 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
>> + * IN THE SOFTWARE.
>> + *
>> + * Authors:
>> + * =====
>> + * Shashank Sharma <shashank.sharma@intel.com>
>> + * Uma Shankar <uma.shankar@intel.com>
>> + * Sonika Jindal <sonika.jindal@intel.com>
>> + */
>> +
>> +#ifndef _I915_CLR_MNGR_H_
>> +#define _I915_CLR_MNGR_H_
>> +
>> +#include "drmP.h"
>> +#include "intel_drv.h"
>> +#include <linux/errno.h>
>> +
>> +/* Framework defs */
>> +#define CLRMGR_PROP_MAX				10
>> +#define CLRMGR_PROP_NAME_MAX				128
>> +#define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
>> +
>> +/* Properties */
>> +enum clrmgr_tweaks {
>> +	csc = 0,
>> +	gamma,
>> +	contrast,
>> +	brightness,
>> +	hue_saturation,
>> +	clrmgr_tweak_invalid
>> +};
>> +
>> +/*
>> +* intel_clrmgr_init:
>> +* Create drm properties for color correction
>> +* Allocate memory to store current color correction
>> +* input: struct drm_device *
>> +*/
>> +void intel_clrmgr_init(struct drm_device *dev);
>> +
>> +/*
>> +* intel_clrmgr_exit
>> +* Destroy color correction DRM properties
>> +* Free allocated memory for color correction storage
>> +* Should be called from CRTC/Plane .destroy function
>> +* input:
>> +* struct drm_device *
>> +*/
>> +void intel_clrmgr_exit(struct drm_device *dev);
>> +
>> +#endif
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index e0beaad..df2dcbd 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -42,6 +42,7 @@
>>   #include <drm/drm_plane_helper.h>
>>   #include <drm/drm_rect.h>
>>   #include <linux/dma_remapping.h>
>> +#include "intel_clrmgr.h"
>>
>>   /* Primary plane formats supported by all gen */
>>   #define COMMON_PRIMARY_FORMATS \
>> @@ -12816,6 +12817,8 @@ void intel_modeset_init(struct drm_device *dev)
>>   		      INTEL_INFO(dev)->num_pipes,
>>   		      INTEL_INFO(dev)->num_pipes > 1 ? "s" : "");
>>
>> +	intel_clrmgr_init(dev);
>> +
>>   	for_each_pipe(dev_priv, pipe) {
>>   		intel_crtc_init(dev, pipe);
>>   		for_each_sprite(pipe, sprite) {
>> @@ -13349,6 +13352,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>>   		intel_connector->unregister(intel_connector);
>>   	}
>>
>> +	intel_clrmgr_exit(dev);
>> +
>>   	drm_mode_config_cleanup(dev);
>>
>>   	intel_cleanup_overlay(dev);
>

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Bob Paauwe]

On Wed, 10 Sep 2014 14:10:01 +0530
"Sharma, Shashank" <shashank.sharma@intel.com> wrote:

> Hello Bob,
> 
> Thanks for your time and review comments.
> Please find my comments inline.
> 
> Regards
> Shashank
> On 9/10/2014 4:21 AM, Bob Paauwe wrote:
> > On Tue, 9 Sep 2014 11:53:13 +0530
> > <shashank.sharma@intel.com> wrote:
> >
> >> From: Shashank Sharma <shashank.sharma@intel.com>
> >>
> >> Color manager is a framework which adds drm properties for
> >> color correction in I915 driver. This framework creates DRM
> >> properties for each color correction feature, and attaches
> >> it to appropriate CRTC/plane based on the property type.
> >> This allows userspace to fine tune the display as per the panel.
> >>
> >> This is the first patch of the series, what this patch does is:
> >> 1. Create 2 new files
> >> 	intel_clrmgr.c
> >> 	intel_clrmgr.h
> >> 2. Add color manager init function, This function will create
> >>     DRM properties for color correction.
> >> 3. Add color manager exit function. This function will destroy
> >>     registered DRM color properties.
> >> 4. Adds a enum for currently listed color correction properties:
> >>     they are:
> >>     CSC correction (wide gamut), Gamma correction, Contrast,
> >>     Brightness, Hue and Saturation
> >>     This enum will be further used to index color properties
> >>     from array of elements.
> >> 5. Add names for vlv color properties.
> >
> > I'd suggest maybe dropping the name "color manager" and "clrmgr" in
> > favor of "color properties" and maybe "color props" as a shorter form.
> >
> I will try to comply with this suggestion.
> >> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> >> ---
> >>   drivers/gpu/drm/i915/Makefile        |  3 +-
> >>   drivers/gpu/drm/i915/intel_clrmgr.c  | 80 ++++++++++++++++++++++++++++++++++++
> >>   drivers/gpu/drm/i915/intel_clrmgr.h  | 70 +++++++++++++++++++++++++++++++
> >>   drivers/gpu/drm/i915/intel_display.c |  5 +++
> >>   4 files changed, 157 insertions(+), 1 deletion(-)
> >>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
> >>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> >>
> >> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> >> index c1dd485..6361c9b 100644
> >> --- a/drivers/gpu/drm/i915/Makefile
> >> +++ b/drivers/gpu/drm/i915/Makefile
> >> @@ -46,7 +46,8 @@ i915-y += intel_bios.o \
> >>   	  intel_modes.o \
> >>   	  intel_overlay.o \
> >>   	  intel_sideband.o \
> >> -	  intel_sprite.o
> >> +	  intel_sprite.o \
> >> +	  intel_clrmgr.o
> >>   i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
> >>   i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> >> new file mode 100644
> >> index 0000000..0def917
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> >> @@ -0,0 +1,80 @@
> >> +/*
> >> + * Copyright © 2014 Intel Corporation
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person obtaining a
> >> + * copy of this software and associated documentation files (the "Software"),
> >> + * to deal in the Software without restriction, including without limitation
> >> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> >> + * and/or sell copies of the Software, and to permit persons to whom the
> >> + * Software is furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice (including the next
> >> + * paragraph) shall be included in all copies or substantial portions of the
> >> + * Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> >> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> >> + * IN THE SOFTWARE.
> >> + *
> >> + * Authors:
> >> + * ======
> >> + * Shashank Sharma <shashank.sharma@intel.com>
> >> + * Uma Shankar <uma.shankar@intel.com>
> >> + * Sonika Jindal <sonika.jindal@intel.com>
> >> + */
> >> +
> >> +#include "i915_drm.h"
> >> +#include "i915_drv.h"
> >> +#include "i915_reg.h"
> >> +#include "intel_clrmgr.h"
> >> +
> >> +/* Names to register with color properties */
> >> +const char *clrmgr_property_names[] = {
> >> +	/* csc */
> >> +	"csc-correction",
> >> +	/* gamma */
> >> +	"gamma-correction",
> >> +	/* contrast */
> >> +	"contrast",
> >> +	/* brightness */
> >> +	"brightness",
> >> +	/* hue_saturation */
> >> +	"hue_saturation"
> >> +	/* add a new prop name here */
> >> +};
> >
> > I don't think you need the comments for each of the names.  The names
> > themselves are descriptive.
> >
> > I haven't looked at the rest of the series yet, but in embedded we've
> > considered hue and saturation separate properties.
> >
> Actually they are, but in VLV hardware they are getting 
> programmed/adjusted via the same register (single), so I am force to 
> combine them together.

But the interface to them should be generic. You should be able to
program them separately by masking out only what needs to change.  At
least that's what we've been doing in the embedded driver for VLV.

I'm not real familiar with the this part of the code but here's what we
have in our driver today.


sat_hue_reg is the contents of the saturation / hue register

To change the saturation:

  (sat_hue_reg & 0xffffc00) | (saturation_val & 0x3ff);

to change the hue:

  (sat_hue_reg & 0xf800ffff) | ((hue_val & 0x7ff) << 16) 

Just looking at our code, we may have bug in the hue calculation, we
limit the max hue to 0x3ff, but then do the masking with 0x7ff. One of
those may be wrong and I'm not sure which.  You probably have something
similar to this in your user-space code today if you're passing in the
actual value for the register.

In general, I don't think we want user-space to have to know the format
of the saturation/hue register.

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Matt Roper]

On Tue, Sep 09, 2014 at 11:53:13AM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> Color manager is a framework which adds drm properties for
> color correction in I915 driver. This framework creates DRM
> properties for each color correction feature, and attaches
> it to appropriate CRTC/plane based on the property type.
> This allows userspace to fine tune the display as per the panel.
> 
> This is the first patch of the series, what this patch does is:
> 1. Create 2 new files
> 	intel_clrmgr.c
> 	intel_clrmgr.h
> 2. Add color manager init function, This function will create
>    DRM properties for color correction.
> 3. Add color manager exit function. This function will destroy
>    registered DRM color properties.
> 4. Adds a enum for currently listed color correction properties:
>    they are:
>    CSC correction (wide gamut), Gamma correction, Contrast,
>    Brightness, Hue and Saturation
>    This enum will be further used to index color properties
>    from array of elements.
> 5. Add names for vlv color properties.
> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> ---
>  drivers/gpu/drm/i915/Makefile        |  3 +-
>  drivers/gpu/drm/i915/intel_clrmgr.c  | 80 ++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_clrmgr.h  | 70 +++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_display.c |  5 +++
>  4 files changed, 157 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index c1dd485..6361c9b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -46,7 +46,8 @@ i915-y += intel_bios.o \
>  	  intel_modes.o \
>  	  intel_overlay.o \
>  	  intel_sideband.o \
> -	  intel_sprite.o
> +	  intel_sprite.o \
> +	  intel_clrmgr.o
>  i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
>  i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
>  
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> new file mode 100644
> index 0000000..0def917
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * ======
> + * Shashank Sharma <shashank.sharma@intel.com>
> + * Uma Shankar <uma.shankar@intel.com>
> + * Sonika Jindal <sonika.jindal@intel.com>
> + */
> +
> +#include "i915_drm.h"
> +#include "i915_drv.h"
> +#include "i915_reg.h"
> +#include "intel_clrmgr.h"
> +
> +/* Names to register with color properties */
> +const char *clrmgr_property_names[] = {
> +	/* csc */
> +	"csc-correction",
> +	/* gamma */
> +	"gamma-correction",
> +	/* contrast */
> +	"contrast",
> +	/* brightness */
> +	"brightness",
> +	/* hue_saturation */
> +	"hue_saturation"
> +	/* add a new prop name here */
> +};

I don't think you really need this array.  A bunch of calls to
drm_property_create() with string literals for the property names seems
plenty clear to me.


> +
> +int intel_clrmgr_create_color_properties(struct drm_device *dev)
> +{
> +	DRM_DEBUG_DRIVER("\n");
> +	return 0;
> +}
> +
> +void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
> +{
> +	DRM_DEBUG_DRIVER("\n");
> +}
> +
> +void intel_clrmgr_init(struct drm_device *dev)
> +{
> +	int ret;
> +
> +	/* Create color properties */
> +	ret = intel_clrmgr_create_color_properties(dev);
> +	if (ret) {
> +		DRM_ERROR("Unable to create %d propert%s\n",
> +			ret, ret > 1 ? "ies" : "y");
> +		return;
> +	}
> +	DRM_DEBUG_DRIVER("Successfully created color properties\n");
> +}

As I noted in reply to your cover letter, I don't think this function
really adds any value.  If we rename
intel_clrmgr_create_color_properties() to something more generic and
move it to be called from intel_modeset_init(), then it will be suitable
for more than just the color management properties you're adding here.
Same goes for the corresponding cleanup function.

> +
> +void intel_clrmgr_exit(struct drm_device *dev)
> +{
> +	/* Remove color properties */
> +	intel_clrmgr_destroy_color_properties(dev);
> +	DRM_DEBUG_DRIVER("Destroyed color properties\n");
> +}
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
> new file mode 100644
> index 0000000..1b7e906
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
> @@ -0,0 +1,70 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * =====
> + * Shashank Sharma <shashank.sharma@intel.com>
> + * Uma Shankar <uma.shankar@intel.com>
> + * Sonika Jindal <sonika.jindal@intel.com>
> + */
> +
> +#ifndef _I915_CLR_MNGR_H_
> +#define _I915_CLR_MNGR_H_
> +
> +#include "drmP.h"
> +#include "intel_drv.h"
> +#include <linux/errno.h>
> +
> +/* Framework defs */
> +#define CLRMGR_PROP_MAX				10
> +#define CLRMGR_PROP_NAME_MAX				128
> +#define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF

These are never used as far as I can see.  I think you can drop them?

> +
> +/* Properties */
> +enum clrmgr_tweaks {
> +	csc = 0,
> +	gamma,
> +	contrast,
> +	brightness,
> +	hue_saturation,
> +	clrmgr_tweak_invalid
> +};

These are just enums into your property name array, right?   I'm not
sure if we need these either.


> +
> +/*
> +* intel_clrmgr_init:
> +* Create drm properties for color correction
> +* Allocate memory to store current color correction
> +* input: struct drm_device *
> +*/
> +void intel_clrmgr_init(struct drm_device *dev);
> +
> +/*
> +* intel_clrmgr_exit
> +* Destroy color correction DRM properties
> +* Free allocated memory for color correction storage
> +* Should be called from CRTC/Plane .destroy function
> +* input:
> +* struct drm_device *
> +*/
> +void intel_clrmgr_exit(struct drm_device *dev);
> +
> +#endif
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index e0beaad..df2dcbd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -42,6 +42,7 @@
>  #include <drm/drm_plane_helper.h>
>  #include <drm/drm_rect.h>
>  #include <linux/dma_remapping.h>
> +#include "intel_clrmgr.h"
>  
>  /* Primary plane formats supported by all gen */
>  #define COMMON_PRIMARY_FORMATS \
> @@ -12816,6 +12817,8 @@ void intel_modeset_init(struct drm_device *dev)
>  		      INTEL_INFO(dev)->num_pipes,
>  		      INTEL_INFO(dev)->num_pipes > 1 ? "s" : "");
>  
> +	intel_clrmgr_init(dev);
> +
>  	for_each_pipe(dev_priv, pipe) {
>  		intel_crtc_init(dev, pipe);
>  		for_each_sprite(pipe, sprite) {
> @@ -13349,6 +13352,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>  		intel_connector->unregister(intel_connector);
>  	}
>  
> +	intel_clrmgr_exit(dev);
> +
>  	drm_mode_config_cleanup(dev);
>  
>  	intel_cleanup_overlay(dev);
> -- 
> 1.9.1
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Sharma, Shashank]

Matt,

Thanks for your time and comments.
Please find mine inline.

Regards
Shashank
On 9/10/2014 6:59 AM, Matt Roper wrote:
> On Tue, Sep 09, 2014 at 11:53:13AM +0530, shashank.sharma@intel.com wrote:
>> From: Shashank Sharma <shashank.sharma@intel.com>
>>
>> Color manager is a framework which adds drm properties for
>> color correction in I915 driver. This framework creates DRM
>> properties for each color correction feature, and attaches
>> it to appropriate CRTC/plane based on the property type.
>> This allows userspace to fine tune the display as per the panel.
>>
>> This is the first patch of the series, what this patch does is:
>> 1. Create 2 new files
>> 	intel_clrmgr.c
>> 	intel_clrmgr.h
>> 2. Add color manager init function, This function will create
>>     DRM properties for color correction.
>> 3. Add color manager exit function. This function will destroy
>>     registered DRM color properties.
>> 4. Adds a enum for currently listed color correction properties:
>>     they are:
>>     CSC correction (wide gamut), Gamma correction, Contrast,
>>     Brightness, Hue and Saturation
>>     This enum will be further used to index color properties
>>     from array of elements.
>> 5. Add names for vlv color properties.
>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>> ---
>>   drivers/gpu/drm/i915/Makefile        |  3 +-
>>   drivers/gpu/drm/i915/intel_clrmgr.c  | 80 ++++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_clrmgr.h  | 70 +++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_display.c |  5 +++
>>   4 files changed, 157 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
>>
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index c1dd485..6361c9b 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -46,7 +46,8 @@ i915-y += intel_bios.o \
>>   	  intel_modes.o \
>>   	  intel_overlay.o \
>>   	  intel_sideband.o \
>> -	  intel_sprite.o
>> +	  intel_sprite.o \
>> +	  intel_clrmgr.o
>>   i915-$(CONFIG_ACPI)		+= intel_acpi.o intel_opregion.o
>>   i915-$(CONFIG_DRM_I915_FBDEV)	+= intel_fbdev.o
>>
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
>> new file mode 100644
>> index 0000000..0def917
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
>> @@ -0,0 +1,80 @@
>> +/*
>> + * Copyright © 2014 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
>> + * IN THE SOFTWARE.
>> + *
>> + * Authors:
>> + * ======
>> + * Shashank Sharma <shashank.sharma@intel.com>
>> + * Uma Shankar <uma.shankar@intel.com>
>> + * Sonika Jindal <sonika.jindal@intel.com>
>> + */
>> +
>> +#include "i915_drm.h"
>> +#include "i915_drv.h"
>> +#include "i915_reg.h"
>> +#include "intel_clrmgr.h"
>> +
>> +/* Names to register with color properties */
>> +const char *clrmgr_property_names[] = {
>> +	/* csc */
>> +	"csc-correction",
>> +	/* gamma */
>> +	"gamma-correction",
>> +	/* contrast */
>> +	"contrast",
>> +	/* brightness */
>> +	"brightness",
>> +	/* hue_saturation */
>> +	"hue_saturation"
>> +	/* add a new prop name here */
>> +};
>
> I don't think you really need this array.  A bunch of calls to
> drm_property_create() with string literals for the property names seems
> plenty clear to me.
>
>
Ok, got it.
>> +
>> +int intel_clrmgr_create_color_properties(struct drm_device *dev)
>> +{
>> +	DRM_DEBUG_DRIVER("\n");
>> +	return 0;
>> +}
>> +
>> +void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
>> +{
>> +	DRM_DEBUG_DRIVER("\n");
>> +}
>> +
>> +void intel_clrmgr_init(struct drm_device *dev)
>> +{
>> +	int ret;
>> +
>> +	/* Create color properties */
>> +	ret = intel_clrmgr_create_color_properties(dev);
>> +	if (ret) {
>> +		DRM_ERROR("Unable to create %d propert%s\n",
>> +			ret, ret > 1 ? "ies" : "y");
>> +		return;
>> +	}
>> +	DRM_DEBUG_DRIVER("Successfully created color properties\n");
>> +}
>
> As I noted in reply to your cover letter, I don't think this function
> really adds any value.  If we rename
> intel_clrmgr_create_color_properties() to something more generic and
> move it to be called from intel_modeset_init(), then it will be suitable
> for more than just the color management properties you're adding here.
> Same goes for the corresponding cleanup function.
>
Same points as discussed in cover-letter.
>> +
>> +void intel_clrmgr_exit(struct drm_device *dev)
>> +{
>> +	/* Remove color properties */
>> +	intel_clrmgr_destroy_color_properties(dev);
>> +	DRM_DEBUG_DRIVER("Destroyed color properties\n");
>> +}
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
>> new file mode 100644
>> index 0000000..1b7e906
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
>> @@ -0,0 +1,70 @@
>> +/*
>> + * Copyright © 2014 Intel Corporation
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
>> + * IN THE SOFTWARE.
>> + *
>> + * Authors:
>> + * =====
>> + * Shashank Sharma <shashank.sharma@intel.com>
>> + * Uma Shankar <uma.shankar@intel.com>
>> + * Sonika Jindal <sonika.jindal@intel.com>
>> + */
>> +
>> +#ifndef _I915_CLR_MNGR_H_
>> +#define _I915_CLR_MNGR_H_
>> +
>> +#include "drmP.h"
>> +#include "intel_drv.h"
>> +#include <linux/errno.h>
>> +
>> +/* Framework defs */
>> +#define CLRMGR_PROP_MAX				10
>> +#define CLRMGR_PROP_NAME_MAX				128
>> +#define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
>
> These are never used as far as I can see.  I think you can drop them?
>
Yes, these were added for plane properties (contrast, brightness, hue 
and sat). I missed while cleaning up.
>> +
>> +/* Properties */
>> +enum clrmgr_tweaks {
>> +	csc = 0,
>> +	gamma,
>> +	contrast,
>> +	brightness,
>> +	hue_saturation,
>> +	clrmgr_tweak_invalid
>> +};
>
> These are just enums into your property name array, right?   I'm not
> sure if we need these either.
>
>
Actually my plan was like this:
One enum(like this), which assigns color property id to each property.
Arrays, arranged in order of this enum for sizes, name and init_values 
of these properties. So it would be easy to access, easy to plug in new 
property, and less hard coding.
+/* Properties */
enum clrmgr_tweaks {
	csc = 0,
	gamma,
	contrast,
	brightness,
	hue_saturation,
	clrmgr_tweak_invalid
};

array color_prop_sizes{size_csc, size_gamma, size_cont, size_bright};
array color_prop_name{"csc", "gamma", "cont", "bright"};
array init_values{{9 init values for CSC} {129 init values for gamma} {1 
default value of contrast} {1 default val for brightness}}

Does it look that bad :) ?
>> +
>> +/*
>> +* intel_clrmgr_init:
>> +* Create drm properties for color correction
>> +* Allocate memory to store current color correction
>> +* input: struct drm_device *
>> +*/
>> +void intel_clrmgr_init(struct drm_device *dev);
>> +
>> +/*
>> +* intel_clrmgr_exit
>> +* Destroy color correction DRM properties
>> +* Free allocated memory for color correction storage
>> +* Should be called from CRTC/Plane .destroy function
>> +* input:
>> +* struct drm_device *
>> +*/
>> +void intel_clrmgr_exit(struct drm_device *dev);
>> +
>> +#endif
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index e0beaad..df2dcbd 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -42,6 +42,7 @@
>>   #include <drm/drm_plane_helper.h>
>>   #include <drm/drm_rect.h>
>>   #include <linux/dma_remapping.h>
>> +#include "intel_clrmgr.h"
>>
>>   /* Primary plane formats supported by all gen */
>>   #define COMMON_PRIMARY_FORMATS \
>> @@ -12816,6 +12817,8 @@ void intel_modeset_init(struct drm_device *dev)
>>   		      INTEL_INFO(dev)->num_pipes,
>>   		      INTEL_INFO(dev)->num_pipes > 1 ? "s" : "");
>>
>> +	intel_clrmgr_init(dev);
>> +
>>   	for_each_pipe(dev_priv, pipe) {
>>   		intel_crtc_init(dev, pipe);
>>   		for_each_sprite(pipe, sprite) {
>> @@ -13349,6 +13352,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>>   		intel_connector->unregister(intel_connector);
>>   	}
>>
>> +	intel_clrmgr_exit(dev);
>> +
>>   	drm_mode_config_cleanup(dev);
>>
>>   	intel_cleanup_overlay(dev);
>> --
>> 1.9.1
>>
>

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Matt Roper]

On Wed, Sep 10, 2014 at 04:50:56PM +0530, Sharma, Shashank wrote:
...
> >>+
> >>+/* Properties */
> >>+enum clrmgr_tweaks {
> >>+	csc = 0,
> >>+	gamma,
> >>+	contrast,
> >>+	brightness,
> >>+	hue_saturation,
> >>+	clrmgr_tweak_invalid
> >>+};
> >
> >These are just enums into your property name array, right?   I'm not
> >sure if we need these either.
> >
> >
> Actually my plan was like this:
> One enum(like this), which assigns color property id to each property.
> Arrays, arranged in order of this enum for sizes, name and
> init_values of these properties. So it would be easy to access, easy
> to plug in new property, and less hard coding.
> +/* Properties */
> enum clrmgr_tweaks {
> 	csc = 0,
> 	gamma,
> 	contrast,
> 	brightness,
> 	hue_saturation,
> 	clrmgr_tweak_invalid
> };
> 
> array color_prop_sizes{size_csc, size_gamma, size_cont, size_bright};
> array color_prop_name{"csc", "gamma", "cont", "bright"};
> array init_values{{9 init values for CSC} {129 init values for
> gamma} {1 default value of contrast} {1 default val for brightness}}
> 
> Does it look that bad :) ?

Okay, I think I see what you were going for, but I'm still not convinced
that pulling these values out into separate arrays is more clear at the
moment.  You still have to make sure your arrays stay in sync and if
there's any control flow (e.g., some properties are only relevant on
certain platforms), then that gets more complicated as well.

I'd suggest not using the arrays for now while we only have a handful of
properties.  Once we have a large list of properties in the driver maybe
we can revisit whether there's a nicer way to stick them in a table and 
simplify the code.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 1/4] drm/i915: Color manager framework for valleyview

[Daniel Vetter]

On Wed, Sep 10, 2014 at 02:17:02PM -0700, Matt Roper wrote:
> On Wed, Sep 10, 2014 at 04:50:56PM +0530, Sharma, Shashank wrote:
> ...
> > >>+
> > >>+/* Properties */
> > >>+enum clrmgr_tweaks {
> > >>+	csc = 0,
> > >>+	gamma,
> > >>+	contrast,
> > >>+	brightness,
> > >>+	hue_saturation,
> > >>+	clrmgr_tweak_invalid
> > >>+};
> > >
> > >These are just enums into your property name array, right?   I'm not
> > >sure if we need these either.
> > >
> > >
> > Actually my plan was like this:
> > One enum(like this), which assigns color property id to each property.
> > Arrays, arranged in order of this enum for sizes, name and
> > init_values of these properties. So it would be easy to access, easy
> > to plug in new property, and less hard coding.
> > +/* Properties */
> > enum clrmgr_tweaks {
> > 	csc = 0,
> > 	gamma,
> > 	contrast,
> > 	brightness,
> > 	hue_saturation,
> > 	clrmgr_tweak_invalid
> > };
> > 
> > array color_prop_sizes{size_csc, size_gamma, size_cont, size_bright};
> > array color_prop_name{"csc", "gamma", "cont", "bright"};
> > array init_values{{9 init values for CSC} {129 init values for
> > gamma} {1 default value of contrast} {1 default val for brightness}}
> > 
> > Does it look that bad :) ?
> 
> Okay, I think I see what you were going for, but I'm still not convinced
> that pulling these values out into separate arrays is more clear at the
> moment.  You still have to make sure your arrays stay in sync and if
> there's any control flow (e.g., some properties are only relevant on
> certain platforms), then that gets more complicated as well.

Yeah, aiming for too much clever structure in your code usually means you
get to toss it all away again for the next generation. Some of the
properties here also look generic enough that we want to make them
universally known, i.e. put them into dev->mode_config so that all drivers
can use them (contrast, brightness, hue_saturation and gamma imo fall into
this cathegory).

> I'd suggest not using the arrays for now while we only have a handful of
> properties.  Once we have a large list of properties in the driver maybe
> we can revisit whether there's a nicer way to stick them in a table and 
> simplify the code.

Yeah, refactoring after the fact is what I recommend when creating
completely new stuff like the color management support here. It's a
different story if there's already existing support infrastructure around,
where it's generally a good idea to reuse them (and refactor first to make
that possible, if it doesn't fit perfectly).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/4] drm/i915: Plug-in color manager attach

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patch does following things:
1. Adds new function to attach color proprties with
   corresponsing crtc / plane objects.
2. Call these attach functions, from corresponding crtc/plane
   init functions.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_clrmgr.c  | 25 +++++++++++--------------
 drivers/gpu/drm/i915/intel_clrmgr.h  | 22 ++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_sprite.c  |  3 +++
 4 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index 0def917..ac0a890 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -32,20 +32,17 @@
 #include "i915_reg.h"
 #include "intel_clrmgr.h"
 
-/* Names to register with color properties */
-const char *clrmgr_property_names[] = {
-	/* csc */
-	"csc-correction",
-	/* gamma */
-	"gamma-correction",
-	/* contrast */
-	"contrast",
-	/* brightness */
-	"brightness",
-	/* hue_saturation */
-	"hue_saturation"
-	/* add a new prop name here */
-};
+void
+intel_attach_plane_color_correction(struct intel_plane *intel_plane)
+{
+	DRM_DEBUG_DRIVER("\n");
+}
+
+void
+intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
+{
+	DRM_DEBUG_DRIVER("\n");
+}
 
 int intel_clrmgr_create_color_properties(struct drm_device *dev)
 {
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index 1b7e906..8cff487 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -50,6 +50,28 @@ enum clrmgr_tweaks {
 };
 
 /*
+* intel_attach_plane_color_correction:
+* Attach plane level color correction DRM properties to
+* corresponding plane objects.
+* This function should be called from plane initialization function
+* for each plane
+* input: intel_plane *
+*/
+void
+intel_attach_plane_color_correction(struct intel_plane *intel_plane);
+
+/*
+* intel_attach_pipe_color_correction:
+* Attach pipe level color correction DRM properties to
+* corresponding CRTC objects.
+* This function should be called from CRTC initialization function
+* for each CRTC
+*  input: intel_crtc *
+*/
+void
+intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc);
+
+/*
 * intel_clrmgr_init:
 * Create drm properties for color correction
 * Allocate memory to store current color correction
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index df2dcbd..a289b44 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12017,6 +12017,8 @@ static void intel_crtc_init(struct drm_device *dev, int pipe)
 
 	drm_crtc_helper_add(&intel_crtc->base, &intel_helper_funcs);
 
+	intel_attach_pipe_color_correction(intel_crtc);
+
 	WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
 	return;
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index fd5f271..cc061de 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -36,6 +36,7 @@
 #include "intel_drv.h"
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
+#include "intel_clrmgr.h"
 
 static int usecs_to_scanlines(const struct drm_display_mode *mode, int usecs)
 {
@@ -1395,6 +1396,8 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
 					   dev->mode_config.rotation_property,
 					   intel_plane->rotation);
 
+	intel_attach_plane_color_correction(intel_plane);
+
  out:
 	return ret;
 }
-- 
1.9.1

Re: [PATCH 2/4] drm/i915: Plug-in color manager attach

[Matt Roper]

On Tue, Sep 09, 2014 at 11:53:14AM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> This patch does following things:
> 1. Adds new function to attach color proprties with
>    corresponsing crtc / plane objects.
> 2. Call these attach functions, from corresponding crtc/plane
>    init functions.
> 
> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_clrmgr.c  | 25 +++++++++++--------------
>  drivers/gpu/drm/i915/intel_clrmgr.h  | 22 ++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_display.c |  2 ++
>  drivers/gpu/drm/i915/intel_sprite.c  |  3 +++
>  4 files changed, 38 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> index 0def917..ac0a890 100644
> --- a/drivers/gpu/drm/i915/intel_clrmgr.c
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> @@ -32,20 +32,17 @@
>  #include "i915_reg.h"
>  #include "intel_clrmgr.h"
>  
> -/* Names to register with color properties */
> -const char *clrmgr_property_names[] = {
> -	/* csc */
> -	"csc-correction",
> -	/* gamma */
> -	"gamma-correction",
> -	/* contrast */
> -	"contrast",
> -	/* brightness */
> -	"brightness",
> -	/* hue_saturation */
> -	"hue_saturation"
> -	/* add a new prop name here */
> -};

It looks like you just added this array in the previous patch, remove it
here, and then you add it back (with only a single element) in the next
patch.  I suspect this is just an artifact of your rebasing and
respinning the patch series, but if you agree my suggestion on the
previous patch to drop the array completely, please make sure that it's
dropped throughout the series to keep the review simple.  :-)


> +void
> +intel_attach_plane_color_correction(struct intel_plane *intel_plane)
> +{
> +	DRM_DEBUG_DRIVER("\n");
> +}
> +
> +void
> +intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
> +{
> +	DRM_DEBUG_DRIVER("\n");
> +}

I think it's generally a bit easier to review if you just add the
functions with their bodies when you actually have the implementation.
I can see where you call these functions in the code below, but without
the bodies present, it makes it a little harder for reviewers to see
whether those are correct.  Since this patch doesn't do anything by
itself, I'd suggest dropping it and just squashing the changes here into
your future patches.

Also, it looks like the plane function remains a noop throughout your
patch series, so I'd just leave it out completely until you start
introducing the plane properties that will use it.

Matt

>  
>  int intel_clrmgr_create_color_properties(struct drm_device *dev)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
> index 1b7e906..8cff487 100644
> --- a/drivers/gpu/drm/i915/intel_clrmgr.h
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
> @@ -50,6 +50,28 @@ enum clrmgr_tweaks {
>  };
>  
>  /*
> +* intel_attach_plane_color_correction:
> +* Attach plane level color correction DRM properties to
> +* corresponding plane objects.
> +* This function should be called from plane initialization function
> +* for each plane
> +* input: intel_plane *
> +*/
> +void
> +intel_attach_plane_color_correction(struct intel_plane *intel_plane);
> +
> +/*
> +* intel_attach_pipe_color_correction:
> +* Attach pipe level color correction DRM properties to
> +* corresponding CRTC objects.
> +* This function should be called from CRTC initialization function
> +* for each CRTC
> +*  input: intel_crtc *
> +*/
> +void
> +intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc);
> +
> +/*
>  * intel_clrmgr_init:
>  * Create drm properties for color correction
>  * Allocate memory to store current color correction
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index df2dcbd..a289b44 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12017,6 +12017,8 @@ static void intel_crtc_init(struct drm_device *dev, int pipe)
>  
>  	drm_crtc_helper_add(&intel_crtc->base, &intel_helper_funcs);
>  
> +	intel_attach_pipe_color_correction(intel_crtc);
> +
>  	WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
>  	return;
>  
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> index fd5f271..cc061de 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -36,6 +36,7 @@
>  #include "intel_drv.h"
>  #include <drm/i915_drm.h>
>  #include "i915_drv.h"
> +#include "intel_clrmgr.h"
>  
>  static int usecs_to_scanlines(const struct drm_display_mode *mode, int usecs)
>  {
> @@ -1395,6 +1396,8 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
>  					   dev->mode_config.rotation_property,
>  					   intel_plane->rotation);
>  
> +	intel_attach_plane_color_correction(intel_plane);
> +
>   out:
>  	return ret;
>  }
> -- 
> 1.9.1
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 2/4] drm/i915: Plug-in color manager attach

[Sharma, Shashank]

Matt,
Thanks for your time and review comments.
Please find mine inline.

Regards
Shashank
On 9/10/2014 6:59 AM, Matt Roper wrote:
> On Tue, Sep 09, 2014 at 11:53:14AM +0530, shashank.sharma@intel.com wrote:
>> From: Shashank Sharma <shashank.sharma@intel.com>
>>
>> This patch does following things:
>> 1. Adds new function to attach color proprties with
>>     corresponsing crtc / plane objects.
>> 2. Call these attach functions, from corresponding crtc/plane
>>     init functions.
>>
>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_clrmgr.c  | 25 +++++++++++--------------
>>   drivers/gpu/drm/i915/intel_clrmgr.h  | 22 ++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_display.c |  2 ++
>>   drivers/gpu/drm/i915/intel_sprite.c  |  3 +++
>>   4 files changed, 38 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
>> index 0def917..ac0a890 100644
>> --- a/drivers/gpu/drm/i915/intel_clrmgr.c
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
>> @@ -32,20 +32,17 @@
>>   #include "i915_reg.h"
>>   #include "intel_clrmgr.h"
>>
>> -/* Names to register with color properties */
>> -const char *clrmgr_property_names[] = {
>> -	/* csc */
>> -	"csc-correction",
>> -	/* gamma */
>> -	"gamma-correction",
>> -	/* contrast */
>> -	"contrast",
>> -	/* brightness */
>> -	"brightness",
>> -	/* hue_saturation */
>> -	"hue_saturation"
>> -	/* add a new prop name here */
>> -};
>
> It looks like you just added this array in the previous patch, remove it
> here, and then you add it back (with only a single element) in the next
> patch.  I suspect this is just an artifact of your rebasing and
> respinning the patch series, but if you agree my suggestion on the
> previous patch to drop the array completely, please make sure that it's
> dropped throughout the series to keep the review simple.  :-)
>
Yes, this is a mistake.
My intention was to add an empty array first, and then with each 
property specific patch, add one name in this array. But looks like
its just creating confusions. I will change this.
>
>> +void
>> +intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>> +{
>> +	DRM_DEBUG_DRIVER("\n");
>> +}
>> +
>> +void
>> +intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
>> +{
>> +	DRM_DEBUG_DRIVER("\n");
>> +}
>
> I think it's generally a bit easier to review if you just add the
> functions with their bodies when you actually have the implementation.
> I can see where you call these functions in the code below, but without
> the bodies present, it makes it a little harder for reviewers to see
> whether those are correct.  Since this patch doesn't do anything by
> itself, I'd suggest dropping it and just squashing the changes here into
> your future patches.
>
Yes, the same case here. I thought the CSC patch will come and fill all 
the functions at a time, and it would be easy to understand, but looks 
like it was a bad idea :)
> Also, it looks like the plane function remains a noop throughout your
> patch series, so I'd just leave it out completely until you start
> introducing the plane properties that will use it.
>
Yes, plane properties are contrast, brightness and hue/sat.
> Matt
>
>>
>>   int intel_clrmgr_create_color_properties(struct drm_device *dev)
>>   {
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
>> index 1b7e906..8cff487 100644
>> --- a/drivers/gpu/drm/i915/intel_clrmgr.h
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
>> @@ -50,6 +50,28 @@ enum clrmgr_tweaks {
>>   };
>>
>>   /*
>> +* intel_attach_plane_color_correction:
>> +* Attach plane level color correction DRM properties to
>> +* corresponding plane objects.
>> +* This function should be called from plane initialization function
>> +* for each plane
>> +* input: intel_plane *
>> +*/
>> +void
>> +intel_attach_plane_color_correction(struct intel_plane *intel_plane);
>> +
>> +/*
>> +* intel_attach_pipe_color_correction:
>> +* Attach pipe level color correction DRM properties to
>> +* corresponding CRTC objects.
>> +* This function should be called from CRTC initialization function
>> +* for each CRTC
>> +*  input: intel_crtc *
>> +*/
>> +void
>> +intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc);
>> +
>> +/*
>>   * intel_clrmgr_init:
>>   * Create drm properties for color correction
>>   * Allocate memory to store current color correction
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index df2dcbd..a289b44 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12017,6 +12017,8 @@ static void intel_crtc_init(struct drm_device *dev, int pipe)
>>
>>   	drm_crtc_helper_add(&intel_crtc->base, &intel_helper_funcs);
>>
>> +	intel_attach_pipe_color_correction(intel_crtc);
>> +
>>   	WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
>>   	return;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
>> index fd5f271..cc061de 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -36,6 +36,7 @@
>>   #include "intel_drv.h"
>>   #include <drm/i915_drm.h>
>>   #include "i915_drv.h"
>> +#include "intel_clrmgr.h"
>>
>>   static int usecs_to_scanlines(const struct drm_display_mode *mode, int usecs)
>>   {
>> @@ -1395,6 +1396,8 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
>>   					   dev->mode_config.rotation_property,
>>   					   intel_plane->rotation);
>>
>> +	intel_attach_plane_color_correction(intel_plane);
>> +
>>    out:
>>   	return ret;
>>   }
>> --
>> 1.9.1
>>
>

[PATCH 3/4] drm/i915: CSC color correction

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

This patch adds support for CSC correction color property.
It does the following:
1. Creates a new DRM property for CSC correction. Adds this into
   mode_config.
2. Attaches this CSC property to calling CRTC. Creates a blob
   to store the correction values, and attaches the blob to CRTC.
3. Adds function intel_clrmgr_set_csc: This is a wrapper function
   which checks the platform type, and calls the valleyview
   specific set_csc function. As different platforms may have different
   methods of setting CSC, wrapper function is required to route to proper
   core CSC set function. In future, the support for other platfroms can be
   plugged-in here. Adding this function as .set_property CSC color property.
4. Adds function vlv_set_csc: core function to program CSC coefficients as per
   vlv specs, and then enable CSC.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/drm_crtc.c          |   4 +-
 drivers/gpu/drm/i915/i915_reg.h     |  11 ++
 drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
 drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
 drivers/gpu/drm/i915/intel_drv.h    |   1 +
 include/drm/drm_crtc.h              |   7 ++
 6 files changed, 244 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 272b66f..be9d110 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3917,7 +3917,7 @@ done:
 	return ret;
 }
 
-static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
+struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
 							  void *data)
 {
 	struct drm_property_blob *blob;
@@ -3944,7 +3944,7 @@ static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev
 	return blob;
 }
 
-static void drm_property_destroy_blob(struct drm_device *dev,
+void drm_property_destroy_blob(struct drm_device *dev,
 			       struct drm_property_blob *blob)
 {
 	drm_mode_object_put(dev, &blob->base);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 20673cc..e3010b3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6183,6 +6183,17 @@ enum punit_power_well {
 #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
 #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
 
+/* VLV color correction registers */
+/* CSC */
+#define PIPECONF_CSC_ENABLE	(1 << 15)
+#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
+								0x600b0)
+#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
+								0x610b0)
+#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
+#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
+#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
+
 /* VLV MIPI registers */
 
 #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
index ac0a890..36c64c1 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.c
+++ b/drivers/gpu/drm/i915/intel_clrmgr.c
@@ -32,6 +32,138 @@
 #include "i915_reg.h"
 #include "intel_clrmgr.h"
 
+/*
+* Names to register with color properties.
+* Sequence must be the same as the order
+* of enum clrmgr_tweaks
+*/
+const char *clrmgr_property_names[] = {
+	/* csc */
+	"csc-correction",
+	/* add a new prop name here */
+};
+
+
+/*
+* Sizes for color properties. This can differ
+* platform by platform, hence 'vlv' prefix
+* The sequence must be same as the order of
+* enum clrmgr_tweaks
+*/
+u32 vlv_color_property_sizes[] = {
+	VLV_CSC_MATRIX_MAX_VALS,
+	/* Add new property size here */
+};
+
+/* Default CSC values to create property with */
+uint64_t vlv_csc_default[VLV_CSC_MATRIX_MAX_VALS] = {
+	0x400, 0, 0, 0, 0x400, 0, 0, 0, 0x400
+};
+
+/*
+* vlv_set_csc
+* Valleyview specific csc correction method.
+* Programs the 6 csc registers with 3x3 correction matrix
+* values.
+* inputs:
+* - intel_crtc*
+* - color manager registered property for csc correction
+* - data: pointer to correction values to be applied
+*/
+/* Enable color space conversion on PIPE */
+bool vlv_set_csc(struct intel_crtc *intel_crtc,
+	struct drm_property *prop, uint64_t values, bool enable)
+{
+	u32 count = 0;
+	u32 c0, c1, c2;
+	u32 pipeconf, csc_reg, data_size;
+	uint64_t *blob_data;
+	uint64_t *data = NULL;
+	struct drm_device *dev = intel_crtc->base.dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_property_blob *blob = intel_crtc->csc_blob;
+
+	/* Sanity */
+	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
+		DRM_ERROR("Invalid/NULL CSC blob\n");
+		return false;
+	}
+	blob_data = (uint64_t *)blob->data;
+
+	/* No need of values to disable property */
+	if (!enable)
+		goto configure;
+
+	/* Enabling property needs correction values */
+	data_size = VLV_CSC_MATRIX_MAX_VALS;
+	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
+	if (!data) {
+		DRM_ERROR("Out of memory\n");
+		return false;
+	}
+
+	if (copy_from_user((void *)data, (const void __user *)values,
+			data_size * sizeof(uint64_t))) {
+		DRM_ERROR("Failed to copy all data\n");
+		kfree(data);
+		return false;
+	}
+
+	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
+	csc_reg = PIPECSC(intel_crtc->pipe);
+
+	/* Read CSC matrix, one row at a time */
+	while (count < VLV_CSC_MATRIX_MAX_VALS) {
+		c0 = data[count] & VLV_CSC_VALUE_MASK;
+		*blob_data++ = c0;
+		c1 = data[count] & VLV_CSC_VALUE_MASK;
+		*blob_data++ = c1;
+		c2 = data[count] & VLV_CSC_VALUE_MASK;
+		*blob_data++ = c2;
+
+		/* C0 is LSB 12bits, C1 is MSB 16-27 */
+		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
+		csc_reg += 4;
+
+		/* C2 is LSB 12 bits */
+		I915_WRITE(csc_reg, c2);
+		csc_reg += 4;
+	}
+
+configure:
+
+	/* Enable / Disable csc correction */
+	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
+	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
+		(pipeconf &= ~PIPECONF_CSC_ENABLE);
+	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
+	POSTING_READ(PIPECONF(intel_crtc->pipe));
+	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
+		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
+
+	kfree(data);
+	return true;
+}
+
+bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
+	struct drm_property *prop, uint64_t values)
+{
+	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+	struct drm_device *dev = intel_crtc->base.dev;
+	bool enable;
+
+	/* First value is enable/disable control, others are data */
+	enable = *((uint64_t *)values);
+	values += (sizeof(uint64_t));
+
+	if (IS_VALLEYVIEW(dev))
+		return vlv_set_csc(intel_crtc, prop, values, enable);
+
+	/* Todo: Support other gen devices */
+	DRM_ERROR("Color correction is supported only on VLV for now\n");
+	return false;
+}
+
 void
 intel_attach_plane_color_correction(struct intel_plane *intel_plane)
 {
@@ -41,18 +173,92 @@ intel_attach_plane_color_correction(struct intel_plane *intel_plane)
 void
 intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
 {
+	struct drm_device *dev = intel_crtc->base.dev;
+	struct drm_mode_object *obj = &intel_crtc->base.base;
+	struct drm_property *property = NULL;
+
 	DRM_DEBUG_DRIVER("\n");
+	mutex_lock(&dev->mode_config.mutex);
+
+	/* color property = csc */
+	property = dev->mode_config.csc_property;
+	if (!property) {
+		DRM_ERROR("No such property to attach\n");
+		goto release_mutex;
+	}
+
+	/* create blob for correction values */
+	intel_crtc->csc_blob = drm_property_create_blob(dev,
+		vlv_color_property_sizes[csc], (void *)vlv_csc_default);
+	if (!intel_crtc->csc_blob) {
+		DRM_ERROR("Failed to create property blob\n");
+		goto release_mutex;
+	}
+
+	/* Attach blob with property */
+	if (drm_object_property_set_value(obj, property,
+			intel_crtc->csc_blob->base.id)) {
+		DRM_ERROR("Failed to attach property blob, destroying\n");
+		drm_property_destroy_blob(dev, intel_crtc->csc_blob);
+		goto release_mutex;
+	}
+
+	DRM_DEBUG_DRIVER("Successfully attached CSC property\n");
+
+release_mutex:
+	mutex_unlock(&dev->mode_config.mutex);
 }
 
 int intel_clrmgr_create_color_properties(struct drm_device *dev)
 {
+	int ret = 0;
+	struct drm_property *property;
+
 	DRM_DEBUG_DRIVER("\n");
-	return 0;
+	mutex_lock(&dev->mode_config.mutex);
+
+	/* CSC correction color property, blob type, size 0 */
+	property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+		clrmgr_property_names[csc], 0);
+	if (!property) {
+		DRM_ERROR("Failed to create property(CSC)\n");
+		ret++;
+	} else {
+		dev->mode_config.csc_property = property;
+		DRM_DEBUG_DRIVER("Created property: CSC\n");
+	}
+
+	mutex_unlock(&dev->mode_config.mutex);
+	return ret;
 }
 
 void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
 {
+	struct drm_crtc *crtc;
+	struct intel_crtc *intel_crtc;
+
 	DRM_DEBUG_DRIVER("\n");
+
+	mutex_lock(&dev->mode_config.mutex);
+
+	/* CSC correction color property */
+	if (dev->mode_config.csc_property) {
+		drm_property_destroy(dev, dev->mode_config.csc_property);
+		dev->mode_config.csc_property = NULL;
+		DRM_DEBUG_DRIVER("Destroyed property: CSC\n");
+	}
+
+	/* Destroy property blob from each CRTC */
+	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+		intel_crtc = to_intel_crtc(crtc);
+		if (intel_crtc->csc_blob) {
+			drm_property_destroy_blob(dev, intel_crtc->csc_blob);
+			intel_crtc->csc_blob = NULL;
+		}
+	}
+
+	mutex_unlock(&dev->mode_config.mutex);
+	DRM_DEBUG_DRIVER("Successfully destroyed all color properties\n");
 }
 
 void intel_clrmgr_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
index 8cff487..5725d6b 100644
--- a/drivers/gpu/drm/i915/intel_clrmgr.h
+++ b/drivers/gpu/drm/i915/intel_clrmgr.h
@@ -39,6 +39,13 @@
 #define CLRMGR_PROP_NAME_MAX				128
 #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
 
+/* CSC */
+ /* CSC / Wide gamut */
+#define VLV_CSC_MATRIX_MAX_VALS		9
+#define VLV_CSC_VALUE_MASK			0xFFF
+#define VLV_CSC_COEFF_SHIFT			16
+
+
 /* Properties */
 enum clrmgr_tweaks {
 	csc = 0,
@@ -50,6 +57,15 @@ enum clrmgr_tweaks {
 };
 
 /*
+* intel_clrmgr_set_csc
+* CSC correction method is different across various
+* gen devices. This wrapper function calls the respective
+* platform specific function to set CSC
+*/
+bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
+	struct drm_property *prop, uint64_t data);
+
+/*
 * intel_attach_plane_color_correction:
 * Attach plane level color correction DRM properties to
 * corresponding plane objects.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7ba5785..a10b9bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -437,6 +437,7 @@ struct intel_crtc {
 
 	int scanline_offset;
 	struct intel_mmio_flip mmio_flip;
+	struct drm_property_blob *csc_blob;
 };
 
 struct intel_plane_wm_parameters {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 31344bf..487ce44 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -851,6 +851,9 @@ struct drm_mode_config {
 	struct drm_property *aspect_ratio_property;
 	struct drm_property *dirty_info_property;
 
+	/* Color correction properties */
+	struct drm_property *csc_property;
+
 	/* dumb ioctl parameters */
 	uint32_t preferred_depth, prefer_shadow;
 
@@ -981,6 +984,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
 						char *path);
 extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 						struct edid *edid);
+extern struct drm_property_blob *drm_property_create_blob(struct drm_device *dev,
+						int length, void *data);
+extern void drm_property_destroy_blob(struct drm_device *dev,
+			       struct drm_property_blob *blob);
 
 static inline bool drm_property_type_is(struct drm_property *property,
 		uint32_t type)
-- 
1.9.1

Re: [PATCH 3/4] drm/i915: CSC color correction

[Bob Paauwe]

On Tue, 9 Sep 2014 11:53:15 +0530
<shashank.sharma@intel.com> wrote:

> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> This patch adds support for CSC correction color property.
> It does the following:
> 1. Creates a new DRM property for CSC correction. Adds this into
>    mode_config.
> 2. Attaches this CSC property to calling CRTC. Creates a blob
>    to store the correction values, and attaches the blob to CRTC.
> 3. Adds function intel_clrmgr_set_csc: This is a wrapper function
>    which checks the platform type, and calls the valleyview
>    specific set_csc function. As different platforms may have different
>    methods of setting CSC, wrapper function is required to route to proper
>    core CSC set function. In future, the support for other platfroms can be
>    plugged-in here. Adding this function as .set_property CSC color property.
> 4. Adds function vlv_set_csc: core function to program CSC coefficients as per
>    vlv specs, and then enable CSC.
> 
> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> ---
>  drivers/gpu/drm/drm_crtc.c          |   4 +-
>  drivers/gpu/drm/i915/i915_reg.h     |  11 ++
>  drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
>  drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
>  drivers/gpu/drm/i915/intel_drv.h    |   1 +
>  include/drm/drm_crtc.h              |   7 ++
>  6 files changed, 244 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 272b66f..be9d110 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3917,7 +3917,7 @@ done:
>  	return ret;
>  }
>  
> -static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
> +struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
>  							  void *data)
>  {
>  	struct drm_property_blob *blob;
> @@ -3944,7 +3944,7 @@ static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev
>  	return blob;
>  }
>  
> -static void drm_property_destroy_blob(struct drm_device *dev,
> +void drm_property_destroy_blob(struct drm_device *dev,
>  			       struct drm_property_blob *blob)
>  {
>  	drm_mode_object_put(dev, &blob->base);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 20673cc..e3010b3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6183,6 +6183,17 @@ enum punit_power_well {
>  #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
>  #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
>  
> +/* VLV color correction registers */
> +/* CSC */
> +#define PIPECONF_CSC_ENABLE	(1 << 15)
> +#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
> +								0x600b0)
> +#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
> +								0x610b0)
> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
> +#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
> +
>  /* VLV MIPI registers */
>  
>  #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> index ac0a890..36c64c1 100644
> --- a/drivers/gpu/drm/i915/intel_clrmgr.c
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> @@ -32,6 +32,138 @@
>  #include "i915_reg.h"
>  #include "intel_clrmgr.h"
>  
> +/*
> +* Names to register with color properties.
> +* Sequence must be the same as the order
> +* of enum clrmgr_tweaks
> +*/
> +const char *clrmgr_property_names[] = {
> +	/* csc */
> +	"csc-correction",
> +	/* add a new prop name here */
> +};
> +
> +
> +/*
> +* Sizes for color properties. This can differ
> +* platform by platform, hence 'vlv' prefix
> +* The sequence must be same as the order of
> +* enum clrmgr_tweaks
> +*/
> +u32 vlv_color_property_sizes[] = {
> +	VLV_CSC_MATRIX_MAX_VALS,
> +	/* Add new property size here */
> +};
> +
> +/* Default CSC values to create property with */
> +uint64_t vlv_csc_default[VLV_CSC_MATRIX_MAX_VALS] = {
> +	0x400, 0, 0, 0, 0x400, 0, 0, 0, 0x400
> +};
> +
> +/*
> +* vlv_set_csc
> +* Valleyview specific csc correction method.
> +* Programs the 6 csc registers with 3x3 correction matrix
> +* values.
> +* inputs:
> +* - intel_crtc*
> +* - color manager registered property for csc correction
> +* - data: pointer to correction values to be applied

The comment isn't matching the function. data is not a pointer, it's a
single 64bit value.  Also, the boolean enable isn't described in the
comment block.

> +*/
> +/* Enable color space conversion on PIPE */
> +bool vlv_set_csc(struct intel_crtc *intel_crtc,
> +	struct drm_property *prop, uint64_t values, bool enable)
> +{
> +	u32 count = 0;
> +	u32 c0, c1, c2;
> +	u32 pipeconf, csc_reg, data_size;
> +	uint64_t *blob_data;
> +	uint64_t *data = NULL;
> +	struct drm_device *dev = intel_crtc->base.dev;
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +	struct drm_property_blob *blob = intel_crtc->csc_blob;
> +
> +	/* Sanity */
> +	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
> +		DRM_ERROR("Invalid/NULL CSC blob\n");
> +		return false;
> +	}
> +	blob_data = (uint64_t *)blob->data;
> +
> +	/* No need of values to disable property */
> +	if (!enable)
> +		goto configure;
> +
> +	/* Enabling property needs correction values */
> +	data_size = VLV_CSC_MATRIX_MAX_VALS;
> +	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
> +	if (!data) {
> +		DRM_ERROR("Out of memory\n");
> +		return false;
> +	}
> +
> +	if (copy_from_user((void *)data, (const void __user *)values,
> +			data_size * sizeof(uint64_t))) {
> +		DRM_ERROR("Failed to copy all data\n");
> +		kfree(data);
> +		return false;
> +	}

I don't think this should be doing a copy_from_user.  It should be the
drm_property code that handles the IOCTL that does that.

The whole handling of the blob property looks suspect to me.  I believe
that the DRM code currently doesn't allow blob type properties to be
set. So you should first have a patch that adds that capability to the
DRM property code.  But I'm not sure that's even the right way to
handle this. 

> +
> +	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
> +	csc_reg = PIPECSC(intel_crtc->pipe);
> +
> +	/* Read CSC matrix, one row at a time */
> +	while (count < VLV_CSC_MATRIX_MAX_VALS) {
> +		c0 = data[count] & VLV_CSC_VALUE_MASK;
> +		*blob_data++ = c0;
> +		c1 = data[count] & VLV_CSC_VALUE_MASK;
> +		*blob_data++ = c1;
> +		c2 = data[count] & VLV_CSC_VALUE_MASK;
> +		*blob_data++ = c2;

You aren't incrementing count after each assignment above, that means
that c0, c1, and c2 are all getting set to the same value. That doesn't
seem right.

> +
> +		/* C0 is LSB 12bits, C1 is MSB 16-27 */
> +		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
> +		csc_reg += 4;
> +
> +		/* C2 is LSB 12 bits */
> +		I915_WRITE(csc_reg, c2);
> +		csc_reg += 4;
> +	}
> +
> +configure:
> +
> +	/* Enable / Disable csc correction */
> +	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
> +	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
> +		(pipeconf &= ~PIPECONF_CSC_ENABLE);
> +	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
> +	POSTING_READ(PIPECONF(intel_crtc->pipe));
> +	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
> +		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
> +
> +	kfree(data);
> +	return true;
> +}
> +
> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> +	struct drm_property *prop, uint64_t values)
> +{
> +	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +	struct drm_device *dev = intel_crtc->base.dev;
> +	bool enable;
> +
> +	/* First value is enable/disable control, others are data */
> +	enable = *((uint64_t *)values);
> +	values += (sizeof(uint64_t));

It looks like you're trying to pass in a user space pointer to some
type of csc structure.  As above, I'm not sure that's the right way to
approach this. Ideally, I think we want to use the standard drm
property types or you're going to have to define a new drm property
type that could be universally used.

> +
> +	if (IS_VALLEYVIEW(dev))
> +		return vlv_set_csc(intel_crtc, prop, values, enable);
> +
> +	/* Todo: Support other gen devices */
> +	DRM_ERROR("Color correction is supported only on VLV for now\n");
> +	return false;
> +}
> +
>  void
>  intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>  {
> @@ -41,18 +173,92 @@ intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>  void
>  intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
>  {
> +	struct drm_device *dev = intel_crtc->base.dev;
> +	struct drm_mode_object *obj = &intel_crtc->base.base;
> +	struct drm_property *property = NULL;
> +
>  	DRM_DEBUG_DRIVER("\n");
> +	mutex_lock(&dev->mode_config.mutex);
> +
> +	/* color property = csc */
> +	property = dev->mode_config.csc_property;
> +	if (!property) {
> +		DRM_ERROR("No such property to attach\n");
> +		goto release_mutex;
> +	}
> +
> +	/* create blob for correction values */
> +	intel_crtc->csc_blob = drm_property_create_blob(dev,
> +		vlv_color_property_sizes[csc], (void *)vlv_csc_default);
> +	if (!intel_crtc->csc_blob) {
> +		DRM_ERROR("Failed to create property blob\n");
> +		goto release_mutex;
> +	}
> +
> +	/* Attach blob with property */
> +	if (drm_object_property_set_value(obj, property,
> +			intel_crtc->csc_blob->base.id)) {
> +		DRM_ERROR("Failed to attach property blob, destroying\n");
> +		drm_property_destroy_blob(dev, intel_crtc->csc_blob);
> +		goto release_mutex;
> +	}
> +
> +	DRM_DEBUG_DRIVER("Successfully attached CSC property\n");
> +
> +release_mutex:
> +	mutex_unlock(&dev->mode_config.mutex);
>  }
>  
>  int intel_clrmgr_create_color_properties(struct drm_device *dev)
>  {
> +	int ret = 0;
> +	struct drm_property *property;
> +
>  	DRM_DEBUG_DRIVER("\n");
> -	return 0;
> +	mutex_lock(&dev->mode_config.mutex);
> +
> +	/* CSC correction color property, blob type, size 0 */
> +	property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +		clrmgr_property_names[csc], 0);
> +	if (!property) {
> +		DRM_ERROR("Failed to create property(CSC)\n");
> +		ret++;
> +	} else {
> +		dev->mode_config.csc_property = property;
> +		DRM_DEBUG_DRIVER("Created property: CSC\n");
> +	}
> +
> +	mutex_unlock(&dev->mode_config.mutex);
> +	return ret;
>  }
>  
>  void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
>  {
> +	struct drm_crtc *crtc;
> +	struct intel_crtc *intel_crtc;
> +
>  	DRM_DEBUG_DRIVER("\n");
> +
> +	mutex_lock(&dev->mode_config.mutex);
> +
> +	/* CSC correction color property */
> +	if (dev->mode_config.csc_property) {
> +		drm_property_destroy(dev, dev->mode_config.csc_property);
> +		dev->mode_config.csc_property = NULL;
> +		DRM_DEBUG_DRIVER("Destroyed property: CSC\n");
> +	}
> +
> +	/* Destroy property blob from each CRTC */
> +	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> +		intel_crtc = to_intel_crtc(crtc);
> +		if (intel_crtc->csc_blob) {
> +			drm_property_destroy_blob(dev, intel_crtc->csc_blob);
> +			intel_crtc->csc_blob = NULL;
> +		}
> +	}
> +
> +	mutex_unlock(&dev->mode_config.mutex);
> +	DRM_DEBUG_DRIVER("Successfully destroyed all color properties\n");
>  }
>  
>  void intel_clrmgr_init(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
> index 8cff487..5725d6b 100644
> --- a/drivers/gpu/drm/i915/intel_clrmgr.h
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
> @@ -39,6 +39,13 @@
>  #define CLRMGR_PROP_NAME_MAX				128
>  #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
>  
> +/* CSC */
> + /* CSC / Wide gamut */
> +#define VLV_CSC_MATRIX_MAX_VALS		9
> +#define VLV_CSC_VALUE_MASK			0xFFF
> +#define VLV_CSC_COEFF_SHIFT			16
> +
> +
>  /* Properties */
>  enum clrmgr_tweaks {
>  	csc = 0,
> @@ -50,6 +57,15 @@ enum clrmgr_tweaks {
>  };
>  
>  /*
> +* intel_clrmgr_set_csc
> +* CSC correction method is different across various
> +* gen devices. This wrapper function calls the respective
> +* platform specific function to set CSC
> +*/
> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> +	struct drm_property *prop, uint64_t data);
> +
> +/*
>  * intel_attach_plane_color_correction:
>  * Attach plane level color correction DRM properties to
>  * corresponding plane objects.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 7ba5785..a10b9bb 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -437,6 +437,7 @@ struct intel_crtc {
>  
>  	int scanline_offset;
>  	struct intel_mmio_flip mmio_flip;
> +	struct drm_property_blob *csc_blob;
>  };
>  
>  struct intel_plane_wm_parameters {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 31344bf..487ce44 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -851,6 +851,9 @@ struct drm_mode_config {
>  	struct drm_property *aspect_ratio_property;
>  	struct drm_property *dirty_info_property;
>  
> +	/* Color correction properties */
> +	struct drm_property *csc_property;
> +
>  	/* dumb ioctl parameters */
>  	uint32_t preferred_depth, prefer_shadow;
>  
> @@ -981,6 +984,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
>  						char *path);
>  extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>  						struct edid *edid);
> +extern struct drm_property_blob *drm_property_create_blob(struct drm_device *dev,
> +						int length, void *data);
> +extern void drm_property_destroy_blob(struct drm_device *dev,
> +			       struct drm_property_blob *blob);
>  
>  static inline bool drm_property_type_is(struct drm_property *property,
>  		uint32_t type)

Re: [PATCH 3/4] drm/i915: CSC color correction

[Sharma, Shashank]

Thanks for your time and review.
Please find my comments inline.

Regards
Shashank

On 9/10/2014 4:21 AM, Bob Paauwe wrote:
> On Tue, 9 Sep 2014 11:53:15 +0530
> <shashank.sharma@intel.com> wrote:
>
>> From: Shashank Sharma <shashank.sharma@intel.com>
>>
>> This patch adds support for CSC correction color property.
>> It does the following:
>> 1. Creates a new DRM property for CSC correction. Adds this into
>>     mode_config.
>> 2. Attaches this CSC property to calling CRTC. Creates a blob
>>     to store the correction values, and attaches the blob to CRTC.
>> 3. Adds function intel_clrmgr_set_csc: This is a wrapper function
>>     which checks the platform type, and calls the valleyview
>>     specific set_csc function. As different platforms may have different
>>     methods of setting CSC, wrapper function is required to route to proper
>>     core CSC set function. In future, the support for other platfroms can be
>>     plugged-in here. Adding this function as .set_property CSC color property.
>> 4. Adds function vlv_set_csc: core function to program CSC coefficients as per
>>     vlv specs, and then enable CSC.
>>
>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>> ---
>>   drivers/gpu/drm/drm_crtc.c          |   4 +-
>>   drivers/gpu/drm/i915/i915_reg.h     |  11 ++
>>   drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
>>   drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
>>   drivers/gpu/drm/i915/intel_drv.h    |   1 +
>>   include/drm/drm_crtc.h              |   7 ++
>>   6 files changed, 244 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 272b66f..be9d110 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -3917,7 +3917,7 @@ done:
>>   	return ret;
>>   }
>>
>> -static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
>> +struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
>>   							  void *data)
>>   {
>>   	struct drm_property_blob *blob;
>> @@ -3944,7 +3944,7 @@ static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev
>>   	return blob;
>>   }
>>
>> -static void drm_property_destroy_blob(struct drm_device *dev,
>> +void drm_property_destroy_blob(struct drm_device *dev,
>>   			       struct drm_property_blob *blob)
>>   {
>>   	drm_mode_object_put(dev, &blob->base);
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index 20673cc..e3010b3 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6183,6 +6183,17 @@ enum punit_power_well {
>>   #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
>>   #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
>>
>> +/* VLV color correction registers */
>> +/* CSC */
>> +#define PIPECONF_CSC_ENABLE	(1 << 15)
>> +#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
>> +								0x600b0)
>> +#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
>> +								0x610b0)
>> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
>> +#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
>> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
>> +
>>   /* VLV MIPI registers */
>>
>>   #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
>> index ac0a890..36c64c1 100644
>> --- a/drivers/gpu/drm/i915/intel_clrmgr.c
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
>> @@ -32,6 +32,138 @@
>>   #include "i915_reg.h"
>>   #include "intel_clrmgr.h"
>>
>> +/*
>> +* Names to register with color properties.
>> +* Sequence must be the same as the order
>> +* of enum clrmgr_tweaks
>> +*/
>> +const char *clrmgr_property_names[] = {
>> +	/* csc */
>> +	"csc-correction",
>> +	/* add a new prop name here */
>> +};
>> +
>> +
>> +/*
>> +* Sizes for color properties. This can differ
>> +* platform by platform, hence 'vlv' prefix
>> +* The sequence must be same as the order of
>> +* enum clrmgr_tweaks
>> +*/
>> +u32 vlv_color_property_sizes[] = {
>> +	VLV_CSC_MATRIX_MAX_VALS,
>> +	/* Add new property size here */
>> +};
>> +
>> +/* Default CSC values to create property with */
>> +uint64_t vlv_csc_default[VLV_CSC_MATRIX_MAX_VALS] = {
>> +	0x400, 0, 0, 0, 0x400, 0, 0, 0, 0x400
>> +};
>> +
>> +/*
>> +* vlv_set_csc
>> +* Valleyview specific csc correction method.
>> +* Programs the 6 csc registers with 3x3 correction matrix
>> +* values.
>> +* inputs:
>> +* - intel_crtc*
>> +* - color manager registered property for csc correction
>> +* - data: pointer to correction values to be applied
>
> The comment isn't matching the function. data is not a pointer, it's a
> single 64bit value.  Also, the boolean enable isn't described in the
> comment block.
>
Yes,Thanks for pointing out. Missed updating comments after design 
change. I will fix this.

>> +*/
>> +/* Enable color space conversion on PIPE */
>> +bool vlv_set_csc(struct intel_crtc *intel_crtc,
>> +	struct drm_property *prop, uint64_t values, bool enable)
>> +{
>> +	u32 count = 0;
>> +	u32 c0, c1, c2;
>> +	u32 pipeconf, csc_reg, data_size;
>> +	uint64_t *blob_data;
>> +	uint64_t *data = NULL;
>> +	struct drm_device *dev = intel_crtc->base.dev;
>> +	struct drm_i915_private *dev_priv = dev->dev_private;
>> +	struct drm_property_blob *blob = intel_crtc->csc_blob;
>> +
>> +	/* Sanity */
>> +	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
>> +		DRM_ERROR("Invalid/NULL CSC blob\n");
>> +		return false;
>> +	}
>> +	blob_data = (uint64_t *)blob->data;
>> +
>> +	/* No need of values to disable property */
>> +	if (!enable)
>> +		goto configure;
>> +
>> +	/* Enabling property needs correction values */
>> +	data_size = VLV_CSC_MATRIX_MAX_VALS;
>> +	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
>> +	if (!data) {
>> +		DRM_ERROR("Out of memory\n");
>> +		return false;
>> +	}
>> +
>> +	if (copy_from_user((void *)data, (const void __user *)values,
>> +			data_size * sizeof(uint64_t))) {
>> +		DRM_ERROR("Failed to copy all data\n");
>> +		kfree(data);
>> +		return false;
>> +	}
>
> I don't think this should be doing a copy_from_user.  It should be the
> drm_property code that handles the IOCTL that does that.
>
> The whole handling of the blob property looks suspect to me.  I believe
> that the DRM code currently doesn't allow blob type properties to be
> set. So you should first have a patch that adds that capability to the
> DRM property code.  But I'm not sure that's even the right way to
> handle this.
>
Humm. This adds another dilemma of how to do this.
I believe blob property type is the only one which suits the CSC 
property, (also gamma correction, with 129 correction values)

Even if we create a set_blob, that will be again doing a 
copy_from_user() only, won't it ?

I can add a patch to do a set_blob in the next patch set. Please have a 
look and let me know if that's what you expect.
>> +
>> +	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
>> +	csc_reg = PIPECSC(intel_crtc->pipe);
>> +
>> +	/* Read CSC matrix, one row at a time */
>> +	while (count < VLV_CSC_MATRIX_MAX_VALS) {
>> +		c0 = data[count] & VLV_CSC_VALUE_MASK;
>> +		*blob_data++ = c0;
>> +		c1 = data[count] & VLV_CSC_VALUE_MASK;
>> +		*blob_data++ = c1;
>> +		c2 = data[count] & VLV_CSC_VALUE_MASK;
>> +		*blob_data++ = c2;
>
> You aren't incrementing count after each assignment above, that means
> that c0, c1, and c2 are all getting set to the same value. That doesn't
> seem right.
>

I am sorry, this is bad. While splitting the patches, I messed here, and 
looks like the unit CSC values were getting applied properly, so dint 
catch this during ULT.
Thanks for pointing this out, will fix this.
>> +
>> +		/* C0 is LSB 12bits, C1 is MSB 16-27 */
>> +		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
>> +		csc_reg += 4;
>> +
>> +		/* C2 is LSB 12 bits */
>> +		I915_WRITE(csc_reg, c2);
>> +		csc_reg += 4;
>> +	}
>> +
>> +configure:
>> +
>> +	/* Enable / Disable csc correction */
>> +	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
>> +	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
>> +		(pipeconf &= ~PIPECONF_CSC_ENABLE);
>> +	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
>> +	POSTING_READ(PIPECONF(intel_crtc->pipe));
>> +	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
>> +		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
>> +
>> +	kfree(data);
>> +	return true;
>> +}
>> +
>> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
>> +	struct drm_property *prop, uint64_t values)
>> +{
>> +	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> +	struct drm_device *dev = intel_crtc->base.dev;
>> +	bool enable;
>> +
>> +	/* First value is enable/disable control, others are data */
>> +	enable = *((uint64_t *)values);
>> +	values += (sizeof(uint64_t));
>
> It looks like you're trying to pass in a user space pointer to some
> type of csc structure.  As above, I'm not sure that's the right way to
> approach this. Ideally, I think we want to use the standard drm
> property types or you're going to have to define a new drm property
> type that could be universally used.
>
Actually, I need to first decide, if we need to enable / disable the 
property. Once we are sure that user space wants to enable it, then I 
need correction coefficients. So I decided to have first byte as 
enable/disable control, and others as correction values.

I dont see any other way of doing it, while coming from drm_property 
interface.
Do you think that we can create a custom/new property type for this 
reason ?
>> +
>> +	if (IS_VALLEYVIEW(dev))
>> +		return vlv_set_csc(intel_crtc, prop, values, enable);
>> +
>> +	/* Todo: Support other gen devices */
>> +	DRM_ERROR("Color correction is supported only on VLV for now\n");
>> +	return false;
>> +}
>> +
>>   void
>>   intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>>   {
>> @@ -41,18 +173,92 @@ intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>>   void
>>   intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
>>   {
>> +	struct drm_device *dev = intel_crtc->base.dev;
>> +	struct drm_mode_object *obj = &intel_crtc->base.base;
>> +	struct drm_property *property = NULL;
>> +
>>   	DRM_DEBUG_DRIVER("\n");
>> +	mutex_lock(&dev->mode_config.mutex);
>> +
>> +	/* color property = csc */
>> +	property = dev->mode_config.csc_property;
>> +	if (!property) {
>> +		DRM_ERROR("No such property to attach\n");
>> +		goto release_mutex;
>> +	}
>> +
>> +	/* create blob for correction values */
>> +	intel_crtc->csc_blob = drm_property_create_blob(dev,
>> +		vlv_color_property_sizes[csc], (void *)vlv_csc_default);
>> +	if (!intel_crtc->csc_blob) {
>> +		DRM_ERROR("Failed to create property blob\n");
>> +		goto release_mutex;
>> +	}
>> +
>> +	/* Attach blob with property */
>> +	if (drm_object_property_set_value(obj, property,
>> +			intel_crtc->csc_blob->base.id)) {
>> +		DRM_ERROR("Failed to attach property blob, destroying\n");
>> +		drm_property_destroy_blob(dev, intel_crtc->csc_blob);
>> +		goto release_mutex;
>> +	}
>> +
>> +	DRM_DEBUG_DRIVER("Successfully attached CSC property\n");
>> +
>> +release_mutex:
>> +	mutex_unlock(&dev->mode_config.mutex);
>>   }
>>
>>   int intel_clrmgr_create_color_properties(struct drm_device *dev)
>>   {
>> +	int ret = 0;
>> +	struct drm_property *property;
>> +
>>   	DRM_DEBUG_DRIVER("\n");
>> -	return 0;
>> +	mutex_lock(&dev->mode_config.mutex);
>> +
>> +	/* CSC correction color property, blob type, size 0 */
>> +	property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> +		clrmgr_property_names[csc], 0);
>> +	if (!property) {
>> +		DRM_ERROR("Failed to create property(CSC)\n");
>> +		ret++;
>> +	} else {
>> +		dev->mode_config.csc_property = property;
>> +		DRM_DEBUG_DRIVER("Created property: CSC\n");
>> +	}
>> +
>> +	mutex_unlock(&dev->mode_config.mutex);
>> +	return ret;
>>   }
>>
>>   void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
>>   {
>> +	struct drm_crtc *crtc;
>> +	struct intel_crtc *intel_crtc;
>> +
>>   	DRM_DEBUG_DRIVER("\n");
>> +
>> +	mutex_lock(&dev->mode_config.mutex);
>> +
>> +	/* CSC correction color property */
>> +	if (dev->mode_config.csc_property) {
>> +		drm_property_destroy(dev, dev->mode_config.csc_property);
>> +		dev->mode_config.csc_property = NULL;
>> +		DRM_DEBUG_DRIVER("Destroyed property: CSC\n");
>> +	}
>> +
>> +	/* Destroy property blob from each CRTC */
>> +	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
>> +		intel_crtc = to_intel_crtc(crtc);
>> +		if (intel_crtc->csc_blob) {
>> +			drm_property_destroy_blob(dev, intel_crtc->csc_blob);
>> +			intel_crtc->csc_blob = NULL;
>> +		}
>> +	}
>> +
>> +	mutex_unlock(&dev->mode_config.mutex);
>> +	DRM_DEBUG_DRIVER("Successfully destroyed all color properties\n");
>>   }
>>
>>   void intel_clrmgr_init(struct drm_device *dev)
>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
>> index 8cff487..5725d6b 100644
>> --- a/drivers/gpu/drm/i915/intel_clrmgr.h
>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
>> @@ -39,6 +39,13 @@
>>   #define CLRMGR_PROP_NAME_MAX				128
>>   #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
>>
>> +/* CSC */
>> + /* CSC / Wide gamut */
>> +#define VLV_CSC_MATRIX_MAX_VALS		9
>> +#define VLV_CSC_VALUE_MASK			0xFFF
>> +#define VLV_CSC_COEFF_SHIFT			16
>> +
>> +
>>   /* Properties */
>>   enum clrmgr_tweaks {
>>   	csc = 0,
>> @@ -50,6 +57,15 @@ enum clrmgr_tweaks {
>>   };
>>
>>   /*
>> +* intel_clrmgr_set_csc
>> +* CSC correction method is different across various
>> +* gen devices. This wrapper function calls the respective
>> +* platform specific function to set CSC
>> +*/
>> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
>> +	struct drm_property *prop, uint64_t data);
>> +
>> +/*
>>   * intel_attach_plane_color_correction:
>>   * Attach plane level color correction DRM properties to
>>   * corresponding plane objects.
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>> index 7ba5785..a10b9bb 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -437,6 +437,7 @@ struct intel_crtc {
>>
>>   	int scanline_offset;
>>   	struct intel_mmio_flip mmio_flip;
>> +	struct drm_property_blob *csc_blob;
>>   };
>>
>>   struct intel_plane_wm_parameters {
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 31344bf..487ce44 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -851,6 +851,9 @@ struct drm_mode_config {
>>   	struct drm_property *aspect_ratio_property;
>>   	struct drm_property *dirty_info_property;
>>
>> +	/* Color correction properties */
>> +	struct drm_property *csc_property;
>> +
>>   	/* dumb ioctl parameters */
>>   	uint32_t preferred_depth, prefer_shadow;
>>
>> @@ -981,6 +984,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
>>   						char *path);
>>   extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>>   						struct edid *edid);
>> +extern struct drm_property_blob *drm_property_create_blob(struct drm_device *dev,
>> +						int length, void *data);
>> +extern void drm_property_destroy_blob(struct drm_device *dev,
>> +			       struct drm_property_blob *blob);
>>
>>   static inline bool drm_property_type_is(struct drm_property *property,
>>   		uint32_t type)
>

Re: [PATCH 3/4] drm/i915: CSC color correction

[Bob Paauwe]

On Wed, 10 Sep 2014 14:25:00 +0530
"Sharma, Shashank" <shashank.sharma@intel.com> wrote:

> Thanks for your time and review.

Thanks for working on this.  This is a feature that the IOTG group is
interested in.

> Please find my comments inline.
> 
> Regards
> Shashank
> 
> On 9/10/2014 4:21 AM, Bob Paauwe wrote:
> > On Tue, 9 Sep 2014 11:53:15 +0530
> > <shashank.sharma@intel.com> wrote:
> >
> >> From: Shashank Sharma <shashank.sharma@intel.com>
> >>
> >> This patch adds support for CSC correction color property.
> >> It does the following:
> >> 1. Creates a new DRM property for CSC correction. Adds this into
> >>     mode_config.
> >> 2. Attaches this CSC property to calling CRTC. Creates a blob
> >>     to store the correction values, and attaches the blob to CRTC.
> >> 3. Adds function intel_clrmgr_set_csc: This is a wrapper function
> >>     which checks the platform type, and calls the valleyview
> >>     specific set_csc function. As different platforms may have different
> >>     methods of setting CSC, wrapper function is required to route to proper
> >>     core CSC set function. In future, the support for other platfroms can be
> >>     plugged-in here. Adding this function as .set_property CSC color property.
> >> 4. Adds function vlv_set_csc: core function to program CSC coefficients as per
> >>     vlv specs, and then enable CSC.
> >>
> >> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> >> ---
> >>   drivers/gpu/drm/drm_crtc.c          |   4 +-
> >>   drivers/gpu/drm/i915/i915_reg.h     |  11 ++
> >>   drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
> >>   drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
> >>   drivers/gpu/drm/i915/intel_drv.h    |   1 +
> >>   include/drm/drm_crtc.h              |   7 ++
> >>   6 files changed, 244 insertions(+), 3 deletions(-)
> >>

> >> +*/
> >> +/* Enable color space conversion on PIPE */
> >> +bool vlv_set_csc(struct intel_crtc *intel_crtc,
> >> +	struct drm_property *prop, uint64_t values, bool enable)
> >> +{
> >> +	u32 count = 0;
> >> +	u32 c0, c1, c2;
> >> +	u32 pipeconf, csc_reg, data_size;
> >> +	uint64_t *blob_data;
> >> +	uint64_t *data = NULL;
> >> +	struct drm_device *dev = intel_crtc->base.dev;
> >> +	struct drm_i915_private *dev_priv = dev->dev_private;
> >> +	struct drm_property_blob *blob = intel_crtc->csc_blob;
> >> +
> >> +	/* Sanity */
> >> +	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
> >> +		DRM_ERROR("Invalid/NULL CSC blob\n");
> >> +		return false;
> >> +	}
> >> +	blob_data = (uint64_t *)blob->data;
> >> +
> >> +	/* No need of values to disable property */
> >> +	if (!enable)
> >> +		goto configure;
> >> +
> >> +	/* Enabling property needs correction values */
> >> +	data_size = VLV_CSC_MATRIX_MAX_VALS;
> >> +	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
> >> +	if (!data) {
> >> +		DRM_ERROR("Out of memory\n");
> >> +		return false;
> >> +	}
> >> +
> >> +	if (copy_from_user((void *)data, (const void __user *)values,
> >> +			data_size * sizeof(uint64_t))) {
> >> +		DRM_ERROR("Failed to copy all data\n");
> >> +		kfree(data);
> >> +		return false;
> >> +	}
> >
> > I don't think this should be doing a copy_from_user.  It should be the
> > drm_property code that handles the IOCTL that does that.
> >
> > The whole handling of the blob property looks suspect to me.  I believe
> > that the DRM code currently doesn't allow blob type properties to be
> > set. So you should first have a patch that adds that capability to the
> > DRM property code.  But I'm not sure that's even the right way to
> > handle this.
> >
> Humm. This adds another dilemma of how to do this.
> I believe blob property type is the only one which suits the CSC 
> property, (also gamma correction, with 129 correction values)
> 
> Even if we create a set_blob, that will be again doing a 
> copy_from_user() only, won't it ?
> 
> I can add a patch to do a set_blob in the next patch set. Please have a 
> look and let me know if that's what you expect.

Yeah, any set_blob function will need to do the copy_from_user but I
think it would be better if this was in the core drm code.  I thought I
saw a patch a while back that added writable property blobs but I don't
see it in the code so maybe it never got in.  Might be worth searching
the archive for that.

> >> +
> >> +	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
> >> +	csc_reg = PIPECSC(intel_crtc->pipe);
> >> +
> >> +	/* Read CSC matrix, one row at a time */
> >> +	while (count < VLV_CSC_MATRIX_MAX_VALS) {
> >> +		c0 = data[count] & VLV_CSC_VALUE_MASK;
> >> +		*blob_data++ = c0;
> >> +		c1 = data[count] & VLV_CSC_VALUE_MASK;
> >> +		*blob_data++ = c1;
> >> +		c2 = data[count] & VLV_CSC_VALUE_MASK;
> >> +		*blob_data++ = c2;
> >
> > You aren't incrementing count after each assignment above, that means
> > that c0, c1, and c2 are all getting set to the same value. That doesn't
> > seem right.
> >
> 
> I am sorry, this is bad. While splitting the patches, I messed here, and 
> looks like the unit CSC values were getting applied properly, so dint 
> catch this during ULT.
> Thanks for pointing this out, will fix this.
> >> +
> >> +		/* C0 is LSB 12bits, C1 is MSB 16-27 */
> >> +		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
> >> +		csc_reg += 4;
> >> +
> >> +		/* C2 is LSB 12 bits */
> >> +		I915_WRITE(csc_reg, c2);
> >> +		csc_reg += 4;
> >> +	}
> >> +
> >> +configure:
> >> +
> >> +	/* Enable / Disable csc correction */
> >> +	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
> >> +	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
> >> +		(pipeconf &= ~PIPECONF_CSC_ENABLE);
> >> +	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
> >> +	POSTING_READ(PIPECONF(intel_crtc->pipe));
> >> +	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
> >> +		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
> >> +
> >> +	kfree(data);
> >> +	return true;
> >> +}
> >> +
> >> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> >> +	struct drm_property *prop, uint64_t values)
> >> +{
> >> +	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >> +	struct drm_device *dev = intel_crtc->base.dev;
> >> +	bool enable;
> >> +
> >> +	/* First value is enable/disable control, others are data */
> >> +	enable = *((uint64_t *)values);
> >> +	values += (sizeof(uint64_t));
> >
> > It looks like you're trying to pass in a user space pointer to some
> > type of csc structure.  As above, I'm not sure that's the right way to
> > approach this. Ideally, I think we want to use the standard drm
> > property types or you're going to have to define a new drm property
> > type that could be universally used.
> >
> Actually, I need to first decide, if we need to enable / disable the 
> property. Once we are sure that user space wants to enable it, then I 
> need correction coefficients. So I decided to have first byte as 
> enable/disable control, and others as correction values.
> 
> I dont see any other way of doing it, while coming from drm_property 
> interface.
> Do you think that we can create a custom/new property type for this 
> reason ?

Since Daniel is OK with a blob type property for this, you might
consider defining a structure for it and then casting the blob pointer
to that data structure.  It would make it clear what you expect the
blob to look like. 

You could also separate the enable/disable from the actual values, you
kind of already do that in the code anyway.  One property that holds
the values and when the set handler takes the data and programs the
registers.  A second property to enable/disable CSC.  All it does is
program the PIPECONF_CSC_ENABLE bit.

Re: [PATCH 3/4] drm/i915: CSC color correction

[Matt Roper]

On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> This patch adds support for CSC correction color property.
> It does the following:
> 1. Creates a new DRM property for CSC correction. Adds this into
>    mode_config.
> 2. Attaches this CSC property to calling CRTC. Creates a blob
>    to store the correction values, and attaches the blob to CRTC.
> 3. Adds function intel_clrmgr_set_csc: This is a wrapper function
>    which checks the platform type, and calls the valleyview
>    specific set_csc function. As different platforms may have different
>    methods of setting CSC, wrapper function is required to route to proper
>    core CSC set function. In future, the support for other platfroms can be
>    plugged-in here. Adding this function as .set_property CSC color property.
> 4. Adds function vlv_set_csc: core function to program CSC coefficients as per
>    vlv specs, and then enable CSC.
> 
> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>

I haven't read up on the hardware programming side of this code to give
any comments there, but I got a bit lost trying to follow your blob
upload handling here.  Like Bob noted, it kind of looks like you're
trying to add userspace blob property upload functionality that would
really belong in the DRM core.  However, in the intermediate/long term
there probably isn't really a need for this kind of blob upload support
because the atomic propertysets will provide the functionality you need;
once we have atomic support, I think it would be better to just make
each of these values an independent property and upload all of the
values together as part of a single property set.  But I realize you're
specifically trying to add add this support in a pre-atomic world which
makes things more challenging.  Atomic is definitely coming, but I think
the timeframe is kind of uncertain still, so it's really going to be up
to the upstream maintainers on how to proceed.  Maybe Daniel can give
you some direction?


Matt

> ---
>  drivers/gpu/drm/drm_crtc.c          |   4 +-
>  drivers/gpu/drm/i915/i915_reg.h     |  11 ++
>  drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
>  drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
>  drivers/gpu/drm/i915/intel_drv.h    |   1 +
>  include/drm/drm_crtc.h              |   7 ++
>  6 files changed, 244 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 272b66f..be9d110 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3917,7 +3917,7 @@ done:
>  	return ret;
>  }
>  
> -static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
> +struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
>  							  void *data)
>  {
>  	struct drm_property_blob *blob;
> @@ -3944,7 +3944,7 @@ static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev
>  	return blob;
>  }
>  
> -static void drm_property_destroy_blob(struct drm_device *dev,
> +void drm_property_destroy_blob(struct drm_device *dev,
>  			       struct drm_property_blob *blob)
>  {
>  	drm_mode_object_put(dev, &blob->base);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 20673cc..e3010b3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6183,6 +6183,17 @@ enum punit_power_well {
>  #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
>  #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
>  
> +/* VLV color correction registers */
> +/* CSC */
> +#define PIPECONF_CSC_ENABLE	(1 << 15)
> +#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
> +								0x600b0)
> +#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
> +								0x610b0)
> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
> +#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
> +
>  /* VLV MIPI registers */
>  
>  #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> index ac0a890..36c64c1 100644
> --- a/drivers/gpu/drm/i915/intel_clrmgr.c
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> @@ -32,6 +32,138 @@
>  #include "i915_reg.h"
>  #include "intel_clrmgr.h"
>  
> +/*
> +* Names to register with color properties.
> +* Sequence must be the same as the order
> +* of enum clrmgr_tweaks
> +*/
> +const char *clrmgr_property_names[] = {
> +	/* csc */
> +	"csc-correction",
> +	/* add a new prop name here */
> +};
> +
> +
> +/*
> +* Sizes for color properties. This can differ
> +* platform by platform, hence 'vlv' prefix
> +* The sequence must be same as the order of
> +* enum clrmgr_tweaks
> +*/
> +u32 vlv_color_property_sizes[] = {
> +	VLV_CSC_MATRIX_MAX_VALS,
> +	/* Add new property size here */
> +};

As with the property names, I'm not sure whether having an array here
gives us much clarity.  I think it's fine to just pass
VLV_CSC_MATRIX_MAX_VALS directly to drm_property_create_blob() in the
code below.


> +
> +/* Default CSC values to create property with */
> +uint64_t vlv_csc_default[VLV_CSC_MATRIX_MAX_VALS] = {
> +	0x400, 0, 0, 0, 0x400, 0, 0, 0, 0x400
> +};
> +
> +/*
> +* vlv_set_csc
> +* Valleyview specific csc correction method.
> +* Programs the 6 csc registers with 3x3 correction matrix
> +* values.
> +* inputs:
> +* - intel_crtc*
> +* - color manager registered property for csc correction
> +* - data: pointer to correction values to be applied
> +*/
> +/* Enable color space conversion on PIPE */
> +bool vlv_set_csc(struct intel_crtc *intel_crtc,
> +	struct drm_property *prop, uint64_t values, bool enable)
> +{
> +	u32 count = 0;
> +	u32 c0, c1, c2;
> +	u32 pipeconf, csc_reg, data_size;
> +	uint64_t *blob_data;
> +	uint64_t *data = NULL;
> +	struct drm_device *dev = intel_crtc->base.dev;
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +	struct drm_property_blob *blob = intel_crtc->csc_blob;
> +
> +	/* Sanity */
> +	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
> +		DRM_ERROR("Invalid/NULL CSC blob\n");
> +		return false;
> +	}
> +	blob_data = (uint64_t *)blob->data;
> +
> +	/* No need of values to disable property */
> +	if (!enable)
> +		goto configure;
> +
> +	/* Enabling property needs correction values */
> +	data_size = VLV_CSC_MATRIX_MAX_VALS;
> +	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
> +	if (!data) {
> +		DRM_ERROR("Out of memory\n");
> +		return false;
> +	}
> +
> +	if (copy_from_user((void *)data, (const void __user *)values,
> +			data_size * sizeof(uint64_t))) {
> +		DRM_ERROR("Failed to copy all data\n");
> +		kfree(data);
> +		return false;
> +	}
> +
> +	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
> +	csc_reg = PIPECSC(intel_crtc->pipe);
> +
> +	/* Read CSC matrix, one row at a time */
> +	while (count < VLV_CSC_MATRIX_MAX_VALS) {
> +		c0 = data[count] & VLV_CSC_VALUE_MASK;
> +		*blob_data++ = c0;
> +		c1 = data[count] & VLV_CSC_VALUE_MASK;
> +		*blob_data++ = c1;
> +		c2 = data[count] & VLV_CSC_VALUE_MASK;
> +		*blob_data++ = c2;
> +
> +		/* C0 is LSB 12bits, C1 is MSB 16-27 */
> +		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
> +		csc_reg += 4;
> +
> +		/* C2 is LSB 12 bits */
> +		I915_WRITE(csc_reg, c2);
> +		csc_reg += 4;
> +	}
> +
> +configure:
> +
> +	/* Enable / Disable csc correction */
> +	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
> +	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
> +		(pipeconf &= ~PIPECONF_CSC_ENABLE);
> +	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
> +	POSTING_READ(PIPECONF(intel_crtc->pipe));
> +	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
> +		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
> +
> +	kfree(data);
> +	return true;
> +}
> +
> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> +	struct drm_property *prop, uint64_t values)
> +{
> +	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> +	struct drm_device *dev = intel_crtc->base.dev;
> +	bool enable;
> +
> +	/* First value is enable/disable control, others are data */
> +	enable = *((uint64_t *)values);
> +	values += (sizeof(uint64_t));
> +
> +	if (IS_VALLEYVIEW(dev))
> +		return vlv_set_csc(intel_crtc, prop, values, enable);
> +
> +	/* Todo: Support other gen devices */
> +	DRM_ERROR("Color correction is supported only on VLV for now\n");
> +	return false;
> +}
> +
>  void
>  intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>  {
> @@ -41,18 +173,92 @@ intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>  void
>  intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
>  {
> +	struct drm_device *dev = intel_crtc->base.dev;
> +	struct drm_mode_object *obj = &intel_crtc->base.base;
> +	struct drm_property *property = NULL;
> +
>  	DRM_DEBUG_DRIVER("\n");
> +	mutex_lock(&dev->mode_config.mutex);
> +
> +	/* color property = csc */
> +	property = dev->mode_config.csc_property;
> +	if (!property) {
> +		DRM_ERROR("No such property to attach\n");
> +		goto release_mutex;
> +	}
> +
> +	/* create blob for correction values */
> +	intel_crtc->csc_blob = drm_property_create_blob(dev,
> +		vlv_color_property_sizes[csc], (void *)vlv_csc_default);
> +	if (!intel_crtc->csc_blob) {
> +		DRM_ERROR("Failed to create property blob\n");
> +		goto release_mutex;
> +	}
> +
> +	/* Attach blob with property */
> +	if (drm_object_property_set_value(obj, property,
> +			intel_crtc->csc_blob->base.id)) {
> +		DRM_ERROR("Failed to attach property blob, destroying\n");
> +		drm_property_destroy_blob(dev, intel_crtc->csc_blob);
> +		goto release_mutex;
> +	}
> +
> +	DRM_DEBUG_DRIVER("Successfully attached CSC property\n");
> +
> +release_mutex:
> +	mutex_unlock(&dev->mode_config.mutex);
>  }
>  
>  int intel_clrmgr_create_color_properties(struct drm_device *dev)
>  {
> +	int ret = 0;
> +	struct drm_property *property;
> +
>  	DRM_DEBUG_DRIVER("\n");
> -	return 0;
> +	mutex_lock(&dev->mode_config.mutex);
> +
> +	/* CSC correction color property, blob type, size 0 */
> +	property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +		clrmgr_property_names[csc], 0);
> +	if (!property) {
> +		DRM_ERROR("Failed to create property(CSC)\n");
> +		ret++;
> +	} else {
> +		dev->mode_config.csc_property = property;
> +		DRM_DEBUG_DRIVER("Created property: CSC\n");
> +	}
> +
> +	mutex_unlock(&dev->mode_config.mutex);
> +	return ret;
>  }
>  
>  void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
>  {
> +	struct drm_crtc *crtc;
> +	struct intel_crtc *intel_crtc;
> +
>  	DRM_DEBUG_DRIVER("\n");
> +
> +	mutex_lock(&dev->mode_config.mutex);
> +
> +	/* CSC correction color property */
> +	if (dev->mode_config.csc_property) {
> +		drm_property_destroy(dev, dev->mode_config.csc_property);
> +		dev->mode_config.csc_property = NULL;
> +		DRM_DEBUG_DRIVER("Destroyed property: CSC\n");
> +	}
> +
> +	/* Destroy property blob from each CRTC */
> +	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> +		intel_crtc = to_intel_crtc(crtc);
> +		if (intel_crtc->csc_blob) {
> +			drm_property_destroy_blob(dev, intel_crtc->csc_blob);
> +			intel_crtc->csc_blob = NULL;
> +		}
> +	}
> +
> +	mutex_unlock(&dev->mode_config.mutex);
> +	DRM_DEBUG_DRIVER("Successfully destroyed all color properties\n");
>  }
>  
>  void intel_clrmgr_init(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
> index 8cff487..5725d6b 100644
> --- a/drivers/gpu/drm/i915/intel_clrmgr.h
> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
> @@ -39,6 +39,13 @@
>  #define CLRMGR_PROP_NAME_MAX				128
>  #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
>  
> +/* CSC */
> + /* CSC / Wide gamut */
> +#define VLV_CSC_MATRIX_MAX_VALS		9
> +#define VLV_CSC_VALUE_MASK			0xFFF
> +#define VLV_CSC_COEFF_SHIFT			16
> +
> +
>  /* Properties */
>  enum clrmgr_tweaks {
>  	csc = 0,
> @@ -50,6 +57,15 @@ enum clrmgr_tweaks {
>  };
>  
>  /*
> +* intel_clrmgr_set_csc
> +* CSC correction method is different across various
> +* gen devices. This wrapper function calls the respective
> +* platform specific function to set CSC
> +*/
> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> +	struct drm_property *prop, uint64_t data);
> +
> +/*
>  * intel_attach_plane_color_correction:
>  * Attach plane level color correction DRM properties to
>  * corresponding plane objects.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 7ba5785..a10b9bb 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -437,6 +437,7 @@ struct intel_crtc {
>  
>  	int scanline_offset;
>  	struct intel_mmio_flip mmio_flip;
> +	struct drm_property_blob *csc_blob;
>  };
>  
>  struct intel_plane_wm_parameters {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 31344bf..487ce44 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -851,6 +851,9 @@ struct drm_mode_config {
>  	struct drm_property *aspect_ratio_property;
>  	struct drm_property *dirty_info_property;
>  
> +	/* Color correction properties */
> +	struct drm_property *csc_property;
> +
>  	/* dumb ioctl parameters */
>  	uint32_t preferred_depth, prefer_shadow;
>  
> @@ -981,6 +984,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
>  						char *path);
>  extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>  						struct edid *edid);
> +extern struct drm_property_blob *drm_property_create_blob(struct drm_device *dev,
> +						int length, void *data);
> +extern void drm_property_destroy_blob(struct drm_device *dev,
> +			       struct drm_property_blob *blob);
>  
>  static inline bool drm_property_type_is(struct drm_property *property,
>  		uint32_t type)
> -- 
> 1.9.1
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 3/4] drm/i915: CSC color correction

[Daniel Vetter]

On Tue, Sep 09, 2014 at 06:30:09PM -0700, Matt Roper wrote:
> On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sharma@intel.com wrote:
> > From: Shashank Sharma <shashank.sharma@intel.com>
> > 
> > This patch adds support for CSC correction color property.
> > It does the following:
> > 1. Creates a new DRM property for CSC correction. Adds this into
> >    mode_config.
> > 2. Attaches this CSC property to calling CRTC. Creates a blob
> >    to store the correction values, and attaches the blob to CRTC.
> > 3. Adds function intel_clrmgr_set_csc: This is a wrapper function
> >    which checks the platform type, and calls the valleyview
> >    specific set_csc function. As different platforms may have different
> >    methods of setting CSC, wrapper function is required to route to proper
> >    core CSC set function. In future, the support for other platfroms can be
> >    plugged-in here. Adding this function as .set_property CSC color property.
> > 4. Adds function vlv_set_csc: core function to program CSC coefficients as per
> >    vlv specs, and then enable CSC.
> > 
> > Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> 
> I haven't read up on the hardware programming side of this code to give
> any comments there, but I got a bit lost trying to follow your blob
> upload handling here.  Like Bob noted, it kind of looks like you're
> trying to add userspace blob property upload functionality that would
> really belong in the DRM core.  However, in the intermediate/long term
> there probably isn't really a need for this kind of blob upload support
> because the atomic propertysets will provide the functionality you need;
> once we have atomic support, I think it would be better to just make
> each of these values an independent property and upload all of the
> values together as part of a single property set.  But I realize you're
> specifically trying to add add this support in a pre-atomic world which
> makes things more challenging.  Atomic is definitely coming, but I think
> the timeframe is kind of uncertain still, so it's really going to be up
> to the upstream maintainers on how to proceed.  Maybe Daniel can give
> you some direction?

I've thought the csc stuff here is just a matrix of register values, and
highly intel specific at that. So might as well keep it as a blob property
for now until either the specific layout changes or some standard for
generic csc emerges.

Overall I still think there's a bit too much indirection - I don't see why
the color manager needs to sit in a separate file with separate
registration functions. Doing it like that rips apart the per-crtc
setup/teardown quite a lot and isn't how properties are handled anywhere
else.
-Daniel

> 
> 
> Matt
> 
> > ---
> >  drivers/gpu/drm/drm_crtc.c          |   4 +-
> >  drivers/gpu/drm/i915/i915_reg.h     |  11 ++
> >  drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
> >  drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
> >  drivers/gpu/drm/i915/intel_drv.h    |   1 +
> >  include/drm/drm_crtc.h              |   7 ++
> >  6 files changed, 244 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 272b66f..be9d110 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -3917,7 +3917,7 @@ done:
> >  	return ret;
> >  }
> >  
> > -static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
> > +struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
> >  							  void *data)
> >  {
> >  	struct drm_property_blob *blob;
> > @@ -3944,7 +3944,7 @@ static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev
> >  	return blob;
> >  }
> >  
> > -static void drm_property_destroy_blob(struct drm_device *dev,
> > +void drm_property_destroy_blob(struct drm_device *dev,
> >  			       struct drm_property_blob *blob)
> >  {
> >  	drm_mode_object_put(dev, &blob->base);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index 20673cc..e3010b3 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6183,6 +6183,17 @@ enum punit_power_well {
> >  #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
> >  #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
> >  
> > +/* VLV color correction registers */
> > +/* CSC */
> > +#define PIPECONF_CSC_ENABLE	(1 << 15)
> > +#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
> > +								0x600b0)
> > +#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
> > +								0x610b0)
> > +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
> > +#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
> > +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
> > +
> >  /* VLV MIPI registers */
> >  
> >  #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
> > diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
> > index ac0a890..36c64c1 100644
> > --- a/drivers/gpu/drm/i915/intel_clrmgr.c
> > +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
> > @@ -32,6 +32,138 @@
> >  #include "i915_reg.h"
> >  #include "intel_clrmgr.h"
> >  
> > +/*
> > +* Names to register with color properties.
> > +* Sequence must be the same as the order
> > +* of enum clrmgr_tweaks
> > +*/
> > +const char *clrmgr_property_names[] = {
> > +	/* csc */
> > +	"csc-correction",
> > +	/* add a new prop name here */
> > +};
> > +
> > +
> > +/*
> > +* Sizes for color properties. This can differ
> > +* platform by platform, hence 'vlv' prefix
> > +* The sequence must be same as the order of
> > +* enum clrmgr_tweaks
> > +*/
> > +u32 vlv_color_property_sizes[] = {
> > +	VLV_CSC_MATRIX_MAX_VALS,
> > +	/* Add new property size here */
> > +};
> 
> As with the property names, I'm not sure whether having an array here
> gives us much clarity.  I think it's fine to just pass
> VLV_CSC_MATRIX_MAX_VALS directly to drm_property_create_blob() in the
> code below.
> 
> 
> > +
> > +/* Default CSC values to create property with */
> > +uint64_t vlv_csc_default[VLV_CSC_MATRIX_MAX_VALS] = {
> > +	0x400, 0, 0, 0, 0x400, 0, 0, 0, 0x400
> > +};
> > +
> > +/*
> > +* vlv_set_csc
> > +* Valleyview specific csc correction method.
> > +* Programs the 6 csc registers with 3x3 correction matrix
> > +* values.
> > +* inputs:
> > +* - intel_crtc*
> > +* - color manager registered property for csc correction
> > +* - data: pointer to correction values to be applied
> > +*/
> > +/* Enable color space conversion on PIPE */
> > +bool vlv_set_csc(struct intel_crtc *intel_crtc,
> > +	struct drm_property *prop, uint64_t values, bool enable)
> > +{
> > +	u32 count = 0;
> > +	u32 c0, c1, c2;
> > +	u32 pipeconf, csc_reg, data_size;
> > +	uint64_t *blob_data;
> > +	uint64_t *data = NULL;
> > +	struct drm_device *dev = intel_crtc->base.dev;
> > +	struct drm_i915_private *dev_priv = dev->dev_private;
> > +	struct drm_property_blob *blob = intel_crtc->csc_blob;
> > +
> > +	/* Sanity */
> > +	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
> > +		DRM_ERROR("Invalid/NULL CSC blob\n");
> > +		return false;
> > +	}
> > +	blob_data = (uint64_t *)blob->data;
> > +
> > +	/* No need of values to disable property */
> > +	if (!enable)
> > +		goto configure;
> > +
> > +	/* Enabling property needs correction values */
> > +	data_size = VLV_CSC_MATRIX_MAX_VALS;
> > +	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
> > +	if (!data) {
> > +		DRM_ERROR("Out of memory\n");
> > +		return false;
> > +	}
> > +
> > +	if (copy_from_user((void *)data, (const void __user *)values,
> > +			data_size * sizeof(uint64_t))) {
> > +		DRM_ERROR("Failed to copy all data\n");
> > +		kfree(data);
> > +		return false;
> > +	}
> > +
> > +	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
> > +	csc_reg = PIPECSC(intel_crtc->pipe);
> > +
> > +	/* Read CSC matrix, one row at a time */
> > +	while (count < VLV_CSC_MATRIX_MAX_VALS) {
> > +		c0 = data[count] & VLV_CSC_VALUE_MASK;
> > +		*blob_data++ = c0;
> > +		c1 = data[count] & VLV_CSC_VALUE_MASK;
> > +		*blob_data++ = c1;
> > +		c2 = data[count] & VLV_CSC_VALUE_MASK;
> > +		*blob_data++ = c2;
> > +
> > +		/* C0 is LSB 12bits, C1 is MSB 16-27 */
> > +		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
> > +		csc_reg += 4;
> > +
> > +		/* C2 is LSB 12 bits */
> > +		I915_WRITE(csc_reg, c2);
> > +		csc_reg += 4;
> > +	}
> > +
> > +configure:
> > +
> > +	/* Enable / Disable csc correction */
> > +	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
> > +	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
> > +		(pipeconf &= ~PIPECONF_CSC_ENABLE);
> > +	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
> > +	POSTING_READ(PIPECONF(intel_crtc->pipe));
> > +	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
> > +		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
> > +
> > +	kfree(data);
> > +	return true;
> > +}
> > +
> > +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> > +	struct drm_property *prop, uint64_t values)
> > +{
> > +	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > +	struct drm_device *dev = intel_crtc->base.dev;
> > +	bool enable;
> > +
> > +	/* First value is enable/disable control, others are data */
> > +	enable = *((uint64_t *)values);
> > +	values += (sizeof(uint64_t));
> > +
> > +	if (IS_VALLEYVIEW(dev))
> > +		return vlv_set_csc(intel_crtc, prop, values, enable);
> > +
> > +	/* Todo: Support other gen devices */
> > +	DRM_ERROR("Color correction is supported only on VLV for now\n");
> > +	return false;
> > +}
> > +
> >  void
> >  intel_attach_plane_color_correction(struct intel_plane *intel_plane)
> >  {
> > @@ -41,18 +173,92 @@ intel_attach_plane_color_correction(struct intel_plane *intel_plane)
> >  void
> >  intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
> >  {
> > +	struct drm_device *dev = intel_crtc->base.dev;
> > +	struct drm_mode_object *obj = &intel_crtc->base.base;
> > +	struct drm_property *property = NULL;
> > +
> >  	DRM_DEBUG_DRIVER("\n");
> > +	mutex_lock(&dev->mode_config.mutex);
> > +
> > +	/* color property = csc */
> > +	property = dev->mode_config.csc_property;
> > +	if (!property) {
> > +		DRM_ERROR("No such property to attach\n");
> > +		goto release_mutex;
> > +	}
> > +
> > +	/* create blob for correction values */
> > +	intel_crtc->csc_blob = drm_property_create_blob(dev,
> > +		vlv_color_property_sizes[csc], (void *)vlv_csc_default);
> > +	if (!intel_crtc->csc_blob) {
> > +		DRM_ERROR("Failed to create property blob\n");
> > +		goto release_mutex;
> > +	}
> > +
> > +	/* Attach blob with property */
> > +	if (drm_object_property_set_value(obj, property,
> > +			intel_crtc->csc_blob->base.id)) {
> > +		DRM_ERROR("Failed to attach property blob, destroying\n");
> > +		drm_property_destroy_blob(dev, intel_crtc->csc_blob);
> > +		goto release_mutex;
> > +	}
> > +
> > +	DRM_DEBUG_DRIVER("Successfully attached CSC property\n");
> > +
> > +release_mutex:
> > +	mutex_unlock(&dev->mode_config.mutex);
> >  }
> >  
> >  int intel_clrmgr_create_color_properties(struct drm_device *dev)
> >  {
> > +	int ret = 0;
> > +	struct drm_property *property;
> > +
> >  	DRM_DEBUG_DRIVER("\n");
> > -	return 0;
> > +	mutex_lock(&dev->mode_config.mutex);
> > +
> > +	/* CSC correction color property, blob type, size 0 */
> > +	property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > +		clrmgr_property_names[csc], 0);
> > +	if (!property) {
> > +		DRM_ERROR("Failed to create property(CSC)\n");
> > +		ret++;
> > +	} else {
> > +		dev->mode_config.csc_property = property;
> > +		DRM_DEBUG_DRIVER("Created property: CSC\n");
> > +	}
> > +
> > +	mutex_unlock(&dev->mode_config.mutex);
> > +	return ret;
> >  }
> >  
> >  void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
> >  {
> > +	struct drm_crtc *crtc;
> > +	struct intel_crtc *intel_crtc;
> > +
> >  	DRM_DEBUG_DRIVER("\n");
> > +
> > +	mutex_lock(&dev->mode_config.mutex);
> > +
> > +	/* CSC correction color property */
> > +	if (dev->mode_config.csc_property) {
> > +		drm_property_destroy(dev, dev->mode_config.csc_property);
> > +		dev->mode_config.csc_property = NULL;
> > +		DRM_DEBUG_DRIVER("Destroyed property: CSC\n");
> > +	}
> > +
> > +	/* Destroy property blob from each CRTC */
> > +	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > +		intel_crtc = to_intel_crtc(crtc);
> > +		if (intel_crtc->csc_blob) {
> > +			drm_property_destroy_blob(dev, intel_crtc->csc_blob);
> > +			intel_crtc->csc_blob = NULL;
> > +		}
> > +	}
> > +
> > +	mutex_unlock(&dev->mode_config.mutex);
> > +	DRM_DEBUG_DRIVER("Successfully destroyed all color properties\n");
> >  }
> >  
> >  void intel_clrmgr_init(struct drm_device *dev)
> > diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
> > index 8cff487..5725d6b 100644
> > --- a/drivers/gpu/drm/i915/intel_clrmgr.h
> > +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
> > @@ -39,6 +39,13 @@
> >  #define CLRMGR_PROP_NAME_MAX				128
> >  #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
> >  
> > +/* CSC */
> > + /* CSC / Wide gamut */
> > +#define VLV_CSC_MATRIX_MAX_VALS		9
> > +#define VLV_CSC_VALUE_MASK			0xFFF
> > +#define VLV_CSC_COEFF_SHIFT			16
> > +
> > +
> >  /* Properties */
> >  enum clrmgr_tweaks {
> >  	csc = 0,
> > @@ -50,6 +57,15 @@ enum clrmgr_tweaks {
> >  };
> >  
> >  /*
> > +* intel_clrmgr_set_csc
> > +* CSC correction method is different across various
> > +* gen devices. This wrapper function calls the respective
> > +* platform specific function to set CSC
> > +*/
> > +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
> > +	struct drm_property *prop, uint64_t data);
> > +
> > +/*
> >  * intel_attach_plane_color_correction:
> >  * Attach plane level color correction DRM properties to
> >  * corresponding plane objects.
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 7ba5785..a10b9bb 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -437,6 +437,7 @@ struct intel_crtc {
> >  
> >  	int scanline_offset;
> >  	struct intel_mmio_flip mmio_flip;
> > +	struct drm_property_blob *csc_blob;
> >  };
> >  
> >  struct intel_plane_wm_parameters {
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 31344bf..487ce44 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -851,6 +851,9 @@ struct drm_mode_config {
> >  	struct drm_property *aspect_ratio_property;
> >  	struct drm_property *dirty_info_property;
> >  
> > +	/* Color correction properties */
> > +	struct drm_property *csc_property;
> > +
> >  	/* dumb ioctl parameters */
> >  	uint32_t preferred_depth, prefer_shadow;
> >  
> > @@ -981,6 +984,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
> >  						char *path);
> >  extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
> >  						struct edid *edid);
> > +extern struct drm_property_blob *drm_property_create_blob(struct drm_device *dev,
> > +						int length, void *data);
> > +extern void drm_property_destroy_blob(struct drm_device *dev,
> > +			       struct drm_property_blob *blob);
> >  
> >  static inline bool drm_property_type_is(struct drm_property *property,
> >  		uint32_t type)
> > -- 
> > 1.9.1
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 3/4] drm/i915: CSC color correction

[Sharma, Shashank]

Hi Daniel,

 > Overall I still think there's a bit too much indirection - I don't 
see why
 > the color manager needs to sit in a separate file with separate
 > registration functions. Doing it like that rips apart the per-crtc
 > setup/teardown quite a lot and isn't how properties are handled anywhere
 > else.

I dont see any issue creating a new file, for 2 reasons:
- I dont see any value in overpopulating the 11K lines file intel-
   display.c any further.
- All these properties are doing color correction, and hence there is
   no harm in keeping them in a functionally separate file.
- How does it tear down per CRTC setup creating a separate file :) ?
   I can see all standard DRM connector property getting created in
   drm_crtc.c, other properties like pfit, force-audio etc are getting
   created in intel_modes.c. They are already spread across functional
   files, so I find it best to create in color correction file.

Regards
Shashank
On 9/10/2014 12:10 PM, Daniel Vetter wrote:
> On Tue, Sep 09, 2014 at 06:30:09PM -0700, Matt Roper wrote:
>> On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sharma@intel.com wrote:
>>> From: Shashank Sharma <shashank.sharma@intel.com>
>>>
>>> This patch adds support for CSC correction color property.
>>> It does the following:
>>> 1. Creates a new DRM property for CSC correction. Adds this into
>>>     mode_config.
>>> 2. Attaches this CSC property to calling CRTC. Creates a blob
>>>     to store the correction values, and attaches the blob to CRTC.
>>> 3. Adds function intel_clrmgr_set_csc: This is a wrapper function
>>>     which checks the platform type, and calls the valleyview
>>>     specific set_csc function. As different platforms may have different
>>>     methods of setting CSC, wrapper function is required to route to proper
>>>     core CSC set function. In future, the support for other platfroms can be
>>>     plugged-in here. Adding this function as .set_property CSC color property.
>>> 4. Adds function vlv_set_csc: core function to program CSC coefficients as per
>>>     vlv specs, and then enable CSC.
>>>
>>> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
>>
>> I haven't read up on the hardware programming side of this code to give
>> any comments there, but I got a bit lost trying to follow your blob
>> upload handling here.  Like Bob noted, it kind of looks like you're
>> trying to add userspace blob property upload functionality that would
>> really belong in the DRM core.  However, in the intermediate/long term
>> there probably isn't really a need for this kind of blob upload support
>> because the atomic propertysets will provide the functionality you need;
>> once we have atomic support, I think it would be better to just make
>> each of these values an independent property and upload all of the
>> values together as part of a single property set.  But I realize you're
>> specifically trying to add add this support in a pre-atomic world which
>> makes things more challenging.  Atomic is definitely coming, but I think
>> the timeframe is kind of uncertain still, so it's really going to be up
>> to the upstream maintainers on how to proceed.  Maybe Daniel can give
>> you some direction?
>
> I've thought the csc stuff here is just a matrix of register values, and
> highly intel specific at that. So might as well keep it as a blob property
> for now until either the specific layout changes or some standard for
> generic csc emerges.
>
> Overall I still think there's a bit too much indirection - I don't see why
> the color manager needs to sit in a separate file with separate
> registration functions. Doing it like that rips apart the per-crtc
> setup/teardown quite a lot and isn't how properties are handled anywhere
> else.
> -Daniel
>
>>
>>
>> Matt
>>
>>> ---
>>>   drivers/gpu/drm/drm_crtc.c          |   4 +-
>>>   drivers/gpu/drm/i915/i915_reg.h     |  11 ++
>>>   drivers/gpu/drm/i915/intel_clrmgr.c | 208 +++++++++++++++++++++++++++++++++++-
>>>   drivers/gpu/drm/i915/intel_clrmgr.h |  16 +++
>>>   drivers/gpu/drm/i915/intel_drv.h    |   1 +
>>>   include/drm/drm_crtc.h              |   7 ++
>>>   6 files changed, 244 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 272b66f..be9d110 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -3917,7 +3917,7 @@ done:
>>>   	return ret;
>>>   }
>>>
>>> -static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
>>> +struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int length,
>>>   							  void *data)
>>>   {
>>>   	struct drm_property_blob *blob;
>>> @@ -3944,7 +3944,7 @@ static struct drm_property_blob *drm_property_create_blob(struct drm_device *dev
>>>   	return blob;
>>>   }
>>>
>>> -static void drm_property_destroy_blob(struct drm_device *dev,
>>> +void drm_property_destroy_blob(struct drm_device *dev,
>>>   			       struct drm_property_blob *blob)
>>>   {
>>>   	drm_mode_object_put(dev, &blob->base);
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>>> index 20673cc..e3010b3 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -6183,6 +6183,17 @@ enum punit_power_well {
>>>   #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
>>>   #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
>>>
>>> +/* VLV color correction registers */
>>> +/* CSC */
>>> +#define PIPECONF_CSC_ENABLE	(1 << 15)
>>> +#define _PIPEACSC		(dev_priv->info.display_mmio_offset + \
>>> +								0x600b0)
>>> +#define _PIPEBCSC		(dev_priv->info.display_mmio_offset + \
>>> +								0x610b0)
>>> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
>>> +#define CSC_OFFSET			(_PIPEBCSC - _PIPEACSC)
>>> +#define PIPECSC(pipe)		(_PIPEACSC + (pipe *  CSC_OFFSET))
>>> +
>>>   /* VLV MIPI registers */
>>>
>>>   #define _MIPIA_PORT_CTRL			(VLV_DISPLAY_BASE + 0x61190)
>>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.c b/drivers/gpu/drm/i915/intel_clrmgr.c
>>> index ac0a890..36c64c1 100644
>>> --- a/drivers/gpu/drm/i915/intel_clrmgr.c
>>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.c
>>> @@ -32,6 +32,138 @@
>>>   #include "i915_reg.h"
>>>   #include "intel_clrmgr.h"
>>>
>>> +/*
>>> +* Names to register with color properties.
>>> +* Sequence must be the same as the order
>>> +* of enum clrmgr_tweaks
>>> +*/
>>> +const char *clrmgr_property_names[] = {
>>> +	/* csc */
>>> +	"csc-correction",
>>> +	/* add a new prop name here */
>>> +};
>>> +
>>> +
>>> +/*
>>> +* Sizes for color properties. This can differ
>>> +* platform by platform, hence 'vlv' prefix
>>> +* The sequence must be same as the order of
>>> +* enum clrmgr_tweaks
>>> +*/
>>> +u32 vlv_color_property_sizes[] = {
>>> +	VLV_CSC_MATRIX_MAX_VALS,
>>> +	/* Add new property size here */
>>> +};
>>
>> As with the property names, I'm not sure whether having an array here
>> gives us much clarity.  I think it's fine to just pass
>> VLV_CSC_MATRIX_MAX_VALS directly to drm_property_create_blob() in the
>> code below.
>>
>>
>>> +
>>> +/* Default CSC values to create property with */
>>> +uint64_t vlv_csc_default[VLV_CSC_MATRIX_MAX_VALS] = {
>>> +	0x400, 0, 0, 0, 0x400, 0, 0, 0, 0x400
>>> +};
>>> +
>>> +/*
>>> +* vlv_set_csc
>>> +* Valleyview specific csc correction method.
>>> +* Programs the 6 csc registers with 3x3 correction matrix
>>> +* values.
>>> +* inputs:
>>> +* - intel_crtc*
>>> +* - color manager registered property for csc correction
>>> +* - data: pointer to correction values to be applied
>>> +*/
>>> +/* Enable color space conversion on PIPE */
>>> +bool vlv_set_csc(struct intel_crtc *intel_crtc,
>>> +	struct drm_property *prop, uint64_t values, bool enable)
>>> +{
>>> +	u32 count = 0;
>>> +	u32 c0, c1, c2;
>>> +	u32 pipeconf, csc_reg, data_size;
>>> +	uint64_t *blob_data;
>>> +	uint64_t *data = NULL;
>>> +	struct drm_device *dev = intel_crtc->base.dev;
>>> +	struct drm_i915_private *dev_priv = dev->dev_private;
>>> +	struct drm_property_blob *blob = intel_crtc->csc_blob;
>>> +
>>> +	/* Sanity */
>>> +	if (!blob || (blob->length != VLV_CSC_MATRIX_MAX_VALS)) {
>>> +		DRM_ERROR("Invalid/NULL CSC blob\n");
>>> +		return false;
>>> +	}
>>> +	blob_data = (uint64_t *)blob->data;
>>> +
>>> +	/* No need of values to disable property */
>>> +	if (!enable)
>>> +		goto configure;
>>> +
>>> +	/* Enabling property needs correction values */
>>> +	data_size = VLV_CSC_MATRIX_MAX_VALS;
>>> +	data = kmalloc(sizeof(uint64_t) * (data_size), GFP_KERNEL);
>>> +	if (!data) {
>>> +		DRM_ERROR("Out of memory\n");
>>> +		return false;
>>> +	}
>>> +
>>> +	if (copy_from_user((void *)data, (const void __user *)values,
>>> +			data_size * sizeof(uint64_t))) {
>>> +		DRM_ERROR("Failed to copy all data\n");
>>> +		kfree(data);
>>> +		return false;
>>> +	}
>>> +
>>> +	DRM_DEBUG_DRIVER("Setting CSC on pipe = %d\n", intel_crtc->pipe);
>>> +	csc_reg = PIPECSC(intel_crtc->pipe);
>>> +
>>> +	/* Read CSC matrix, one row at a time */
>>> +	while (count < VLV_CSC_MATRIX_MAX_VALS) {
>>> +		c0 = data[count] & VLV_CSC_VALUE_MASK;
>>> +		*blob_data++ = c0;
>>> +		c1 = data[count] & VLV_CSC_VALUE_MASK;
>>> +		*blob_data++ = c1;
>>> +		c2 = data[count] & VLV_CSC_VALUE_MASK;
>>> +		*blob_data++ = c2;
>>> +
>>> +		/* C0 is LSB 12bits, C1 is MSB 16-27 */
>>> +		I915_WRITE(csc_reg, (c1 << VLV_CSC_COEFF_SHIFT) | c0);
>>> +		csc_reg += 4;
>>> +
>>> +		/* C2 is LSB 12 bits */
>>> +		I915_WRITE(csc_reg, c2);
>>> +		csc_reg += 4;
>>> +	}
>>> +
>>> +configure:
>>> +
>>> +	/* Enable / Disable csc correction */
>>> +	pipeconf = I915_READ(PIPECONF(intel_crtc->pipe));
>>> +	enable ? (pipeconf |= PIPECONF_CSC_ENABLE) :
>>> +		(pipeconf &= ~PIPECONF_CSC_ENABLE);
>>> +	I915_WRITE(PIPECONF(intel_crtc->pipe), pipeconf);
>>> +	POSTING_READ(PIPECONF(intel_crtc->pipe));
>>> +	DRM_DEBUG_DRIVER("CSC successfully %s pipe %C\n",
>>> +		enable ? "enabled" : "disabled", pipe_name(intel_crtc->pipe));
>>> +
>>> +	kfree(data);
>>> +	return true;
>>> +}
>>> +
>>> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
>>> +	struct drm_property *prop, uint64_t values)
>>> +{
>>> +	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>>> +	struct drm_device *dev = intel_crtc->base.dev;
>>> +	bool enable;
>>> +
>>> +	/* First value is enable/disable control, others are data */
>>> +	enable = *((uint64_t *)values);
>>> +	values += (sizeof(uint64_t));
>>> +
>>> +	if (IS_VALLEYVIEW(dev))
>>> +		return vlv_set_csc(intel_crtc, prop, values, enable);
>>> +
>>> +	/* Todo: Support other gen devices */
>>> +	DRM_ERROR("Color correction is supported only on VLV for now\n");
>>> +	return false;
>>> +}
>>> +
>>>   void
>>>   intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>>>   {
>>> @@ -41,18 +173,92 @@ intel_attach_plane_color_correction(struct intel_plane *intel_plane)
>>>   void
>>>   intel_attach_pipe_color_correction(struct intel_crtc *intel_crtc)
>>>   {
>>> +	struct drm_device *dev = intel_crtc->base.dev;
>>> +	struct drm_mode_object *obj = &intel_crtc->base.base;
>>> +	struct drm_property *property = NULL;
>>> +
>>>   	DRM_DEBUG_DRIVER("\n");
>>> +	mutex_lock(&dev->mode_config.mutex);
>>> +
>>> +	/* color property = csc */
>>> +	property = dev->mode_config.csc_property;
>>> +	if (!property) {
>>> +		DRM_ERROR("No such property to attach\n");
>>> +		goto release_mutex;
>>> +	}
>>> +
>>> +	/* create blob for correction values */
>>> +	intel_crtc->csc_blob = drm_property_create_blob(dev,
>>> +		vlv_color_property_sizes[csc], (void *)vlv_csc_default);
>>> +	if (!intel_crtc->csc_blob) {
>>> +		DRM_ERROR("Failed to create property blob\n");
>>> +		goto release_mutex;
>>> +	}
>>> +
>>> +	/* Attach blob with property */
>>> +	if (drm_object_property_set_value(obj, property,
>>> +			intel_crtc->csc_blob->base.id)) {
>>> +		DRM_ERROR("Failed to attach property blob, destroying\n");
>>> +		drm_property_destroy_blob(dev, intel_crtc->csc_blob);
>>> +		goto release_mutex;
>>> +	}
>>> +
>>> +	DRM_DEBUG_DRIVER("Successfully attached CSC property\n");
>>> +
>>> +release_mutex:
>>> +	mutex_unlock(&dev->mode_config.mutex);
>>>   }
>>>
>>>   int intel_clrmgr_create_color_properties(struct drm_device *dev)
>>>   {
>>> +	int ret = 0;
>>> +	struct drm_property *property;
>>> +
>>>   	DRM_DEBUG_DRIVER("\n");
>>> -	return 0;
>>> +	mutex_lock(&dev->mode_config.mutex);
>>> +
>>> +	/* CSC correction color property, blob type, size 0 */
>>> +	property = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>>> +		clrmgr_property_names[csc], 0);
>>> +	if (!property) {
>>> +		DRM_ERROR("Failed to create property(CSC)\n");
>>> +		ret++;
>>> +	} else {
>>> +		dev->mode_config.csc_property = property;
>>> +		DRM_DEBUG_DRIVER("Created property: CSC\n");
>>> +	}
>>> +
>>> +	mutex_unlock(&dev->mode_config.mutex);
>>> +	return ret;
>>>   }
>>>
>>>   void intel_clrmgr_destroy_color_properties(struct drm_device *dev)
>>>   {
>>> +	struct drm_crtc *crtc;
>>> +	struct intel_crtc *intel_crtc;
>>> +
>>>   	DRM_DEBUG_DRIVER("\n");
>>> +
>>> +	mutex_lock(&dev->mode_config.mutex);
>>> +
>>> +	/* CSC correction color property */
>>> +	if (dev->mode_config.csc_property) {
>>> +		drm_property_destroy(dev, dev->mode_config.csc_property);
>>> +		dev->mode_config.csc_property = NULL;
>>> +		DRM_DEBUG_DRIVER("Destroyed property: CSC\n");
>>> +	}
>>> +
>>> +	/* Destroy property blob from each CRTC */
>>> +	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
>>> +		intel_crtc = to_intel_crtc(crtc);
>>> +		if (intel_crtc->csc_blob) {
>>> +			drm_property_destroy_blob(dev, intel_crtc->csc_blob);
>>> +			intel_crtc->csc_blob = NULL;
>>> +		}
>>> +	}
>>> +
>>> +	mutex_unlock(&dev->mode_config.mutex);
>>> +	DRM_DEBUG_DRIVER("Successfully destroyed all color properties\n");
>>>   }
>>>
>>>   void intel_clrmgr_init(struct drm_device *dev)
>>> diff --git a/drivers/gpu/drm/i915/intel_clrmgr.h b/drivers/gpu/drm/i915/intel_clrmgr.h
>>> index 8cff487..5725d6b 100644
>>> --- a/drivers/gpu/drm/i915/intel_clrmgr.h
>>> +++ b/drivers/gpu/drm/i915/intel_clrmgr.h
>>> @@ -39,6 +39,13 @@
>>>   #define CLRMGR_PROP_NAME_MAX				128
>>>   #define CLRMGR_PROP_RANGE_MAX				0xFFFFFFFFFFFFFFFF
>>>
>>> +/* CSC */
>>> + /* CSC / Wide gamut */
>>> +#define VLV_CSC_MATRIX_MAX_VALS		9
>>> +#define VLV_CSC_VALUE_MASK			0xFFF
>>> +#define VLV_CSC_COEFF_SHIFT			16
>>> +
>>> +
>>>   /* Properties */
>>>   enum clrmgr_tweaks {
>>>   	csc = 0,
>>> @@ -50,6 +57,15 @@ enum clrmgr_tweaks {
>>>   };
>>>
>>>   /*
>>> +* intel_clrmgr_set_csc
>>> +* CSC correction method is different across various
>>> +* gen devices. This wrapper function calls the respective
>>> +* platform specific function to set CSC
>>> +*/
>>> +bool intel_clrmgr_set_csc(struct drm_crtc *crtc,
>>> +	struct drm_property *prop, uint64_t data);
>>> +
>>> +/*
>>>   * intel_attach_plane_color_correction:
>>>   * Attach plane level color correction DRM properties to
>>>   * corresponding plane objects.
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>>> index 7ba5785..a10b9bb 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -437,6 +437,7 @@ struct intel_crtc {
>>>
>>>   	int scanline_offset;
>>>   	struct intel_mmio_flip mmio_flip;
>>> +	struct drm_property_blob *csc_blob;
>>>   };
>>>
>>>   struct intel_plane_wm_parameters {
>>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>>> index 31344bf..487ce44 100644
>>> --- a/include/drm/drm_crtc.h
>>> +++ b/include/drm/drm_crtc.h
>>> @@ -851,6 +851,9 @@ struct drm_mode_config {
>>>   	struct drm_property *aspect_ratio_property;
>>>   	struct drm_property *dirty_info_property;
>>>
>>> +	/* Color correction properties */
>>> +	struct drm_property *csc_property;
>>> +
>>>   	/* dumb ioctl parameters */
>>>   	uint32_t preferred_depth, prefer_shadow;
>>>
>>> @@ -981,6 +984,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
>>>   						char *path);
>>>   extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>>>   						struct edid *edid);
>>> +extern struct drm_property_blob *drm_property_create_blob(struct drm_device *dev,
>>> +						int length, void *data);
>>> +extern void drm_property_destroy_blob(struct drm_device *dev,
>>> +			       struct drm_property_blob *blob);
>>>
>>>   static inline bool drm_property_type_is(struct drm_property *property,
>>>   		uint32_t type)
>>> --
>>> 1.9.1
>>>
>>
>> --
>> Matt Roper
>> Graphics Software Engineer
>> IoTG Platform Enabling & Development
>> Intel Corporation
>> (916) 356-2795
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

Re: [PATCH 3/4] drm/i915: CSC color correction

[Daniel Vetter]

On Wed, Sep 10, 2014 at 2:05 PM, Sharma, Shashank
<shashank.sharma@intel.com> wrote:
> - How does it tear down per CRTC setup creating a separate file :) ?
>   I can see all standard DRM connector property getting created in
>   drm_crtc.c, other properties like pfit, force-audio etc are getting
>   created in intel_modes.c. They are already spread across functional
>   files, so I find it best to create in color correction file.

I don't mean creating/destroying the properties, but
attaching/detaching them. I agree with Matt that that should happen
directly in the crtc setup/teardown functions.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 3/4] drm/i915: CSC color correction

[Matt Roper]

On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> This patch adds support for CSC correction color property.
> It does the following:
> 1. Creates a new DRM property for CSC correction. Adds this into
>    mode_config.
...

One thing I forgot to ask in my response yesterday...does it make sense
to create this property in dev->mode_config rather than in dev_priv?
Some properties (like the plane rotation property that went in a little
while ago) do seem like a good match for dev->mode_config because
they're generic concepts that a lot of different drivers will want to
reuse (and in some cases the common core/helper library code might want
to make use of them as well, as we do in restore_fbdev_mode()).  But
it's unclear to me whether non-Intel hardware handles color correction
similarly enough that the CSC property you're creating here is something
other drivers will ever use, or whether it will always be an
Intel-specific thing.  My understanding is that the values here are very
Intel-specific, so there's never going to be an opportunity for
core/helper library code to make use of the property, right?  If this
does turn out to be an Intel-only property, then it's probably better to
move it to dev_priv (where we have a couple of our connector properties
today).

If you do decide that there's potential for reuse by other drivers and
that you want to keep this in dev->mode_config you'll want to make sure
you Cc the dri-devel mailing list on the patches that touch the DRM core
files.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 3/4] drm/i915: CSC color correction

[Daniel Vetter]

On Wed, Sep 10, 2014 at 03:17:34PM -0700, Matt Roper wrote:
> On Tue, Sep 09, 2014 at 11:53:15AM +0530, shashank.sharma@intel.com wrote:
> > From: Shashank Sharma <shashank.sharma@intel.com>
> > 
> > This patch adds support for CSC correction color property.
> > It does the following:
> > 1. Creates a new DRM property for CSC correction. Adds this into
> >    mode_config.
> ...
> 
> One thing I forgot to ask in my response yesterday...does it make sense
> to create this property in dev->mode_config rather than in dev_priv?
> Some properties (like the plane rotation property that went in a little
> while ago) do seem like a good match for dev->mode_config because
> they're generic concepts that a lot of different drivers will want to
> reuse (and in some cases the common core/helper library code might want
> to make use of them as well, as we do in restore_fbdev_mode()).  But
> it's unclear to me whether non-Intel hardware handles color correction
> similarly enough that the CSC property you're creating here is something
> other drivers will ever use, or whether it will always be an
> Intel-specific thing.  My understanding is that the values here are very
> Intel-specific, so there's never going to be an opportunity for
> core/helper library code to make use of the property, right?  If this
> does turn out to be an Intel-only property, then it's probably better to
> move it to dev_priv (where we have a couple of our connector properties
> today).
> 
> If you do decide that there's potential for reuse by other drivers and
> that you want to keep this in dev->mode_config you'll want to make sure
> you Cc the dri-devel mailing list on the patches that touch the DRM core
> files.

The csc matrix looks platform-specific enough (I expect it'll be different
on big-core, but haven't checked tbh) that a generic property imo doesn't
make sense. But others from the color manager task certainly qualify,
which is another reason not to smash them all together into a tightly knit
boundle.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 4/4] drm/i915: Add set_protpery function

[shashank.sharma]

From: Shashank Sharma <shashank.sharma@intel.com>

Add set_property function in CRTC ops.
This function will be required for color correction properties.
Userspace will do a set_property operation on CRTC object, to
do display tuning or color correction.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index a289b44..7e3cdb2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11503,11 +11503,29 @@ out_config:
 	return ret;
 }
 
+static int intel_crtc_set_property(struct drm_crtc *crtc,
+			    struct drm_property *property, uint64_t val)
+{
+	struct drm_device *dev = crtc->dev;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	/* CSC correction */
+	if (property == dev->mode_config.csc_property) {
+		if (!intel_clrmgr_set_csc(crtc, property, val)) {
+			DRM_ERROR("Failed to set CSC correction\n");
+			return -EFAULT;
+		}
+		DRM_DEBUG_DRIVER("Set CSC correction successful\n");
+	}
+}
+
 static const struct drm_crtc_funcs intel_crtc_funcs = {
 	.gamma_set = intel_crtc_gamma_set,
 	.set_config = intel_crtc_set_config,
 	.destroy = intel_crtc_destroy,
 	.page_flip = intel_crtc_page_flip,
+	.set_property = intel_crtc_set_property,
 };
 
 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
-- 
1.9.1

Re: [PATCH 0/4] Color manager framework

[Matt Roper]

On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sharma@intel.com wrote:
> From: Shashank Sharma <shashank.sharma@intel.com>
> 
> Color manager is an extention to i915 driver which provides display
> tuning and color-correction properties to user space, via DRM propery
> interface.Different Intel platforms support different color tuning capabilities
> which can be exploited using this framework.
> 
> This patch set adds color correction for VLV, and the code is written
> in such a way that new color properties and support for other platforms can
> be pluggen in, using the same architecture.
> 
> For the design discussion, right now only one color correction property (CSC)
> has been added. Once we agree on the design, gamma-correction, contrast, brightness,
> and hue/saturation would be followed by the same.
> 
> What this patch set does, is:
> 1. Color manager framework for valleyview:
> Add basic functions of framework, to create and destroy DRM properties for
> color correction. It also adds header, enums and defines.
> 
> 2. Plug-in color manager attach
> Attach created color properties, with the objects. Basically properties get attached to
> two type of objects, crtc (pipe level correction) and plane (plane level correction).
> 
> 3. CSC color correction
> First color correction method.
> - Add color property for CSC during init. 
> - Add blob to keep correction values
> - Attach DRM CSC propery with each CRTC object
> - Core CSC correction for VLV
> 
> 4. Add set_property function for intel CRTC.
> This function checks the type of the property, and calls the
> appropriate high level function (intel_clrmgr_set_csc), which does
> platform check and calls the core platform color correction
> function (vlv_set_csc)
> 
> V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
> - Creating only one property per color correction, and attaching it to every DRM object.
> - No additional data structures on top of DRM property.
> - No registeration of color property, just create and attach.
> - Added properties in dev->mode_config

Hi Shashank, thanks for incorporating the feedback from the last review
round.  This patchset is definitely moving in the right direction,
although I still feel that there's still a little bit of unnecessary
work/complexity in creating a "framework" here where we probably don't
need it.

I'll give some more detailed responses on your individual patches, but
at a high level I don't really see the need to treat color correction
properties (csc, gamma, etc.) in a special way with their own
registration framework.  There are really three things to consider here:
 * How/where to create the properties
 * How/where to attach properties to CRTC's and/or planes
 * How to handle property changes

For creating properties, at the moment you're doing that via
intel_modeset_init() -> intel_clrmgr_init() ->
intel_clrmgr_create_color_properties().  Presumably we'll add other
(non-color correction) properties to the driver in the future, so it
seems like it would be simpler if we just renamed your
intel_clrmgr_create_color_properties() to something like
intel_modeset_create_properties() and called it directly from
intel_modeset_init().  I don't see the intermediate intel_clrmgr_init()
adding any value at the moment, so I think it can be removed.

For attaching properties, I'm not sure I see where that is happening in
your current patchset.  You have an intel_attach_pipe_color_correction()
function that sounds promising, but the implementation doesn't seem to
actually be calling drm_object_attach_property() that I can see; instead
it seems to be creating a blob value and trying to set it on the object.
Honestly I think all you really need is a single call to:

        drm_object_attach_property(intel_crtc->base.base,
                dev->mode_config.csc_property, 0);

at the bottom of intel_crtc_init() where you have have your call to
intel_attach_pipe_color_correction() right now.  I'm not sure if this
code is expected to stay VLV-specific or whether you've only provided a
single platform for RFC/POC purposes, but if it is expected to stay
limited to VLV you'll probably also want to do an
'if (IS_VALLEYVIEW(dev_priv))' before doing the attach so that the property
won't even show up on platforms where you haven't implemented support
yet.

Also note that aside from the design/coding stuff there are a couple
more bookkeeping things that will need to be done before this patch set
gets accepted upstream.  I think you'll need to update the DocBook
documentation in Documentation/DocBook/drm.tmpl with a description of
your new properties (that compiles into documentation like you see at
https://www.kernel.org/doc/htmldocs/drm/drm-kms-properties.html) and
you'll need to add some tests to intel-gpu-tools to exercise this new
functionality.

I'll provide some more specific feedback on your individual patches.


Matt

> 
> Shashank Sharma (4):
>   drm/i915: Color manager framework for valleyview
>   drm/i915: Plug-in color manager attach
>   drm/i915: CSC color correction
>   drm/i915: Add set_protpery function
> 
>  drivers/gpu/drm/drm_crtc.c           |   4 +-
>  drivers/gpu/drm/i915/Makefile        |   3 +-
>  drivers/gpu/drm/i915/i915_reg.h      |  11 ++
>  drivers/gpu/drm/i915/intel_clrmgr.c  | 283 +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_clrmgr.h  | 108 +++++++++++++
>  drivers/gpu/drm/i915/intel_display.c |  25 ++++
>  drivers/gpu/drm/i915/intel_drv.h     |   1 +
>  drivers/gpu/drm/i915/intel_sprite.c  |   3 +
>  include/drm/drm_crtc.h               |   7 +
>  9 files changed, 442 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> 
> -- 
> 1.9.1
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 0/4] Color manager framework

[Sharma, Shashank]

Hello Matt,

Thanks for your detailed descriptions, reviews comments and time.
Please find my comments inline.

Regards
Shashank
On 9/10/2014 6:58 AM, Matt Roper wrote:
> On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sharma@intel.com wrote:
>> From: Shashank Sharma <shashank.sharma@intel.com>
>>
>> Color manager is an extention to i915 driver which provides display
>> tuning and color-correction properties to user space, via DRM propery
>> interface.Different Intel platforms support different color tuning capabilities
>> which can be exploited using this framework.
>>
>> This patch set adds color correction for VLV, and the code is written
>> in such a way that new color properties and support for other platforms can
>> be pluggen in, using the same architecture.
>>
>> For the design discussion, right now only one color correction property (CSC)
>> has been added. Once we agree on the design, gamma-correction, contrast, brightness,
>> and hue/saturation would be followed by the same.
>>
>> What this patch set does, is:
>> 1. Color manager framework for valleyview:
>> Add basic functions of framework, to create and destroy DRM properties for
>> color correction. It also adds header, enums and defines.
>>
>> 2. Plug-in color manager attach
>> Attach created color properties, with the objects. Basically properties get attached to
>> two type of objects, crtc (pipe level correction) and plane (plane level correction).
>>
>> 3. CSC color correction
>> First color correction method.
>> - Add color property for CSC during init.
>> - Add blob to keep correction values
>> - Attach DRM CSC propery with each CRTC object
>> - Core CSC correction for VLV
>>
>> 4. Add set_property function for intel CRTC.
>> This function checks the type of the property, and calls the
>> appropriate high level function (intel_clrmgr_set_csc), which does
>> platform check and calls the core platform color correction
>> function (vlv_set_csc)
>>
>> V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
>> - Creating only one property per color correction, and attaching it to every DRM object.
>> - No additional data structures on top of DRM property.
>> - No registeration of color property, just create and attach.
>> - Added properties in dev->mode_config
>
> Hi Shashank, thanks for incorporating the feedback from the last review
> round.  This patchset is definitely moving in the right direction,
> although I still feel that there's still a little bit of unnecessary
> work/complexity in creating a "framework" here where we probably don't
> need it.
>
> I'll give some more detailed responses on your individual patches, but
> at a high level I don't really see the need to treat color correction
> properties (csc, gamma, etc.) in a special way with their own
> registration framework.  There are really three things to consider here:
>   * How/where to create the properties
>   * How/where to attach properties to CRTC's and/or planes
>   * How to handle property changes
>
> For creating properties, at the moment you're doing that via
> intel_modeset_init() -> intel_clrmgr_init() ->
> intel_clrmgr_create_color_properties().  Presumably we'll add other
> (non-color correction) properties to the driver in the future, so it
> seems like it would be simpler if we just renamed your
> intel_clrmgr_create_color_properties() to something like
> intel_modeset_create_properties() and called it directly from
> intel_modeset_init().  I don't see the intermediate intel_clrmgr_init()
> adding any value at the moment, so I think it can be removed.
>
I got this point Matt, and we can do this. The only confusion I have is, 
we already have places where we create properties, and if we are 
intending to create different type of properties in this function, would 
that align with the previous property creations places ?

At least we have a common ground among the color properties,  that's why 
I am sticking them together.

If you dont like this, the other common ground is CRTC/plane properties. 
These are the first of CRTC or plane properties.
So I can create a intel_create_crtc_properties()
> For attaching properties, I'm not sure I see where that is happening in
> your current patchset.  You have an intel_attach_pipe_color_correction()
> function that sounds promising, but the implementation doesn't seem to
> actually be calling drm_object_attach_property() that I can see; instead
> it seems to be creating a blob value and trying to set it on the object.
> Honestly I think all you really need is a single call to:
>
>          drm_object_attach_property(intel_crtc->base.base,
>                  dev->mode_config.csc_property, 0);
>
Yes, I was suppose to do this, and then create a blob. I will change this.
> at the bottom of intel_crtc_init() where you have have your call to
> intel_attach_pipe_color_correction() right now.  I'm not sure if this
> code is expected to stay VLV-specific or whether you've only provided a
> single platform for RFC/POC purposes, but if it is expected to stay
> limited to VLV you'll probably also want to do an
> 'if (IS_VALLEYVIEW(dev_priv))' before doing the attach so that the property
> won't even show up on platforms where you haven't implemented support
> yet.
This will be platform independent code. For any platform, we will attach 
all the CRTC properties here. But as you rightly mentioned, I will add 
the check once we are ok with this architecture.
>
> Also note that aside from the design/coding stuff there are a couple
> more bookkeeping things that will need to be done before this patch set
> gets accepted upstream.  I think you'll need to update the DocBook
> documentation in Documentation/DocBook/drm.tmpl with a description of
> your new properties (that compiles into documentation like you see at
> https://www.kernel.org/doc/htmldocs/drm/drm-kms-properties.html) and
> you'll need to add some tests to intel-gpu-tools to exercise this new
> functionality.
>
Yes, Once we are OK with the architecture, I will add documentation for 
all the color properties together. Right now we have one command line 
test app to test this, which I will convert into an IGT.
> I'll provide some more specific feedback on your individual patches.
>
>
> Matt
>
>>
>> Shashank Sharma (4):
>>    drm/i915: Color manager framework for valleyview
>>    drm/i915: Plug-in color manager attach
>>    drm/i915: CSC color correction
>>    drm/i915: Add set_protpery function
>>
>>   drivers/gpu/drm/drm_crtc.c           |   4 +-
>>   drivers/gpu/drm/i915/Makefile        |   3 +-
>>   drivers/gpu/drm/i915/i915_reg.h      |  11 ++
>>   drivers/gpu/drm/i915/intel_clrmgr.c  | 283 +++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_clrmgr.h  | 108 +++++++++++++
>>   drivers/gpu/drm/i915/intel_display.c |  25 ++++
>>   drivers/gpu/drm/i915/intel_drv.h     |   1 +
>>   drivers/gpu/drm/i915/intel_sprite.c  |   3 +
>>   include/drm/drm_crtc.h               |   7 +
>>   9 files changed, 442 insertions(+), 3 deletions(-)
>>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
>>   create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
>>
>> --
>> 1.9.1
>>
>

Re: [PATCH 0/4] Color manager framework

[Matt Roper]

On Wed, Sep 10, 2014 at 04:38:43PM +0530, Sharma, Shashank wrote:
> Hello Matt,
> 
> Thanks for your detailed descriptions, reviews comments and time.
> Please find my comments inline.
> 
> Regards
> Shashank
> On 9/10/2014 6:58 AM, Matt Roper wrote:
> >On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sharma@intel.com wrote:
> >>From: Shashank Sharma <shashank.sharma@intel.com>
> >>
> >>Color manager is an extention to i915 driver which provides display
> >>tuning and color-correction properties to user space, via DRM propery
> >>interface.Different Intel platforms support different color tuning capabilities
> >>which can be exploited using this framework.
> >>
> >>This patch set adds color correction for VLV, and the code is written
> >>in such a way that new color properties and support for other platforms can
> >>be pluggen in, using the same architecture.
> >>
> >>For the design discussion, right now only one color correction property (CSC)
> >>has been added. Once we agree on the design, gamma-correction, contrast, brightness,
> >>and hue/saturation would be followed by the same.
> >>
> >>What this patch set does, is:
> >>1. Color manager framework for valleyview:
> >>Add basic functions of framework, to create and destroy DRM properties for
> >>color correction. It also adds header, enums and defines.
> >>
> >>2. Plug-in color manager attach
> >>Attach created color properties, with the objects. Basically properties get attached to
> >>two type of objects, crtc (pipe level correction) and plane (plane level correction).
> >>
> >>3. CSC color correction
> >>First color correction method.
> >>- Add color property for CSC during init.
> >>- Add blob to keep correction values
> >>- Attach DRM CSC propery with each CRTC object
> >>- Core CSC correction for VLV
> >>
> >>4. Add set_property function for intel CRTC.
> >>This function checks the type of the property, and calls the
> >>appropriate high level function (intel_clrmgr_set_csc), which does
> >>platform check and calls the core platform color correction
> >>function (vlv_set_csc)
> >>
> >>V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
> >>- Creating only one property per color correction, and attaching it to every DRM object.
> >>- No additional data structures on top of DRM property.
> >>- No registeration of color property, just create and attach.
> >>- Added properties in dev->mode_config
> >
> >Hi Shashank, thanks for incorporating the feedback from the last review
> >round.  This patchset is definitely moving in the right direction,
> >although I still feel that there's still a little bit of unnecessary
> >work/complexity in creating a "framework" here where we probably don't
> >need it.
> >
> >I'll give some more detailed responses on your individual patches, but
> >at a high level I don't really see the need to treat color correction
> >properties (csc, gamma, etc.) in a special way with their own
> >registration framework.  There are really three things to consider here:
> >  * How/where to create the properties
> >  * How/where to attach properties to CRTC's and/or planes
> >  * How to handle property changes
> >
> >For creating properties, at the moment you're doing that via
> >intel_modeset_init() -> intel_clrmgr_init() ->
> >intel_clrmgr_create_color_properties().  Presumably we'll add other
> >(non-color correction) properties to the driver in the future, so it
> >seems like it would be simpler if we just renamed your
> >intel_clrmgr_create_color_properties() to something like
> >intel_modeset_create_properties() and called it directly from
> >intel_modeset_init().  I don't see the intermediate intel_clrmgr_init()
> >adding any value at the moment, so I think it can be removed.
> >
> I got this point Matt, and we can do this. The only confusion I have
> is, we already have places where we create properties, and if we are
> intending to create different type of properties in this function,
> would that align with the previous property creations places ?
> 
> At least we have a common ground among the color properties,  that's
> why I am sticking them together.
> 
> If you dont like this, the other common ground is CRTC/plane
> properties. These are the first of CRTC or plane properties.
> So I can create a intel_create_crtc_properties()

We do actually have one plane property (rotation) now that just went
into the driver.  But you're right that we also have connector
properties that are handled a bit differently at the moment.  There are
'audio' and 'Broadcast RGB' properties that are stored in dev_priv and
get created the first time they are attached to a connector.  Personally
I don't see a problem with moving the creation of those two properties
into your new intel_modeset_create_properties() function; it's not like
we're using up a ton of memory in cases where we don't have any relevant
connectors to attach them to.

We also have a whole bunch of SDVO/TV connector properties that are
actually stored in the connector itself, which seems a bit off to me.
Generally properties get stored in a central location like dev or
dev_priv so that they can be shared between multiple objects.  I'm
not really familiar with the SDVO code, so I'm not sure if there's some
subtle reason the code was written this way or whether it's just really
old code that nobody ever cleaned up (git blame does indicate that most
of that logic is from 2009-2010).

I'd be inclined to move the audio and broadcast properties in alongside
your new color property setup code (and just make it a generic property
setup function as noted).  Same with the rotation plane property.  Since
the SDVO/TV properties are a bit of a different world (and since I'm not
personally familiar enough with it to feel comfortable touching it), I'd
leave those as they are for now.  But if any of the OTC reviewers think
differently, I'll defer to their judgment.


Matt


> >For attaching properties, I'm not sure I see where that is happening in
> >your current patchset.  You have an intel_attach_pipe_color_correction()
> >function that sounds promising, but the implementation doesn't seem to
> >actually be calling drm_object_attach_property() that I can see; instead
> >it seems to be creating a blob value and trying to set it on the object.
> >Honestly I think all you really need is a single call to:
> >
> >         drm_object_attach_property(intel_crtc->base.base,
> >                 dev->mode_config.csc_property, 0);
> >
> Yes, I was suppose to do this, and then create a blob. I will change this.
> >at the bottom of intel_crtc_init() where you have have your call to
> >intel_attach_pipe_color_correction() right now.  I'm not sure if this
> >code is expected to stay VLV-specific or whether you've only provided a
> >single platform for RFC/POC purposes, but if it is expected to stay
> >limited to VLV you'll probably also want to do an
> >'if (IS_VALLEYVIEW(dev_priv))' before doing the attach so that the property
> >won't even show up on platforms where you haven't implemented support
> >yet.
> This will be platform independent code. For any platform, we will
> attach all the CRTC properties here. But as you rightly mentioned, I
> will add the check once we are ok with this architecture.
> >
> >Also note that aside from the design/coding stuff there are a couple
> >more bookkeeping things that will need to be done before this patch set
> >gets accepted upstream.  I think you'll need to update the DocBook
> >documentation in Documentation/DocBook/drm.tmpl with a description of
> >your new properties (that compiles into documentation like you see at
> >https://www.kernel.org/doc/htmldocs/drm/drm-kms-properties.html) and
> >you'll need to add some tests to intel-gpu-tools to exercise this new
> >functionality.
> >
> Yes, Once we are OK with the architecture, I will add documentation
> for all the color properties together. Right now we have one command
> line test app to test this, which I will convert into an IGT.
> >I'll provide some more specific feedback on your individual patches.
> >
> >
> >Matt
> >
> >>
> >>Shashank Sharma (4):
> >>   drm/i915: Color manager framework for valleyview
> >>   drm/i915: Plug-in color manager attach
> >>   drm/i915: CSC color correction
> >>   drm/i915: Add set_protpery function
> >>
> >>  drivers/gpu/drm/drm_crtc.c           |   4 +-
> >>  drivers/gpu/drm/i915/Makefile        |   3 +-
> >>  drivers/gpu/drm/i915/i915_reg.h      |  11 ++
> >>  drivers/gpu/drm/i915/intel_clrmgr.c  | 283 +++++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/i915/intel_clrmgr.h  | 108 +++++++++++++
> >>  drivers/gpu/drm/i915/intel_display.c |  25 ++++
> >>  drivers/gpu/drm/i915/intel_drv.h     |   1 +
> >>  drivers/gpu/drm/i915/intel_sprite.c  |   3 +
> >>  include/drm/drm_crtc.h               |   7 +
> >>  9 files changed, 442 insertions(+), 3 deletions(-)
> >>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.c
> >>  create mode 100644 drivers/gpu/drm/i915/intel_clrmgr.h
> >>
> >>--
> >>1.9.1
> >>
> >

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 0/4] Color manager framework

[Daniel Vetter]

On Wed, Sep 10, 2014 at 11:15:11AM -0700, Matt Roper wrote:
> On Wed, Sep 10, 2014 at 04:38:43PM +0530, Sharma, Shashank wrote:
> > Hello Matt,
> > 
> > Thanks for your detailed descriptions, reviews comments and time.
> > Please find my comments inline.
> > 
> > Regards
> > Shashank
> > On 9/10/2014 6:58 AM, Matt Roper wrote:
> > >On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sharma@intel.com wrote:
> > >>From: Shashank Sharma <shashank.sharma@intel.com>
> > >>
> > >>Color manager is an extention to i915 driver which provides display
> > >>tuning and color-correction properties to user space, via DRM propery
> > >>interface.Different Intel platforms support different color tuning capabilities
> > >>which can be exploited using this framework.
> > >>
> > >>This patch set adds color correction for VLV, and the code is written
> > >>in such a way that new color properties and support for other platforms can
> > >>be pluggen in, using the same architecture.
> > >>
> > >>For the design discussion, right now only one color correction property (CSC)
> > >>has been added. Once we agree on the design, gamma-correction, contrast, brightness,
> > >>and hue/saturation would be followed by the same.
> > >>
> > >>What this patch set does, is:
> > >>1. Color manager framework for valleyview:
> > >>Add basic functions of framework, to create and destroy DRM properties for
> > >>color correction. It also adds header, enums and defines.
> > >>
> > >>2. Plug-in color manager attach
> > >>Attach created color properties, with the objects. Basically properties get attached to
> > >>two type of objects, crtc (pipe level correction) and plane (plane level correction).
> > >>
> > >>3. CSC color correction
> > >>First color correction method.
> > >>- Add color property for CSC during init.
> > >>- Add blob to keep correction values
> > >>- Attach DRM CSC propery with each CRTC object
> > >>- Core CSC correction for VLV
> > >>
> > >>4. Add set_property function for intel CRTC.
> > >>This function checks the type of the property, and calls the
> > >>appropriate high level function (intel_clrmgr_set_csc), which does
> > >>platform check and calls the core platform color correction
> > >>function (vlv_set_csc)
> > >>
> > >>V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
> > >>- Creating only one property per color correction, and attaching it to every DRM object.
> > >>- No additional data structures on top of DRM property.
> > >>- No registeration of color property, just create and attach.
> > >>- Added properties in dev->mode_config
> > >
> > >Hi Shashank, thanks for incorporating the feedback from the last review
> > >round.  This patchset is definitely moving in the right direction,
> > >although I still feel that there's still a little bit of unnecessary
> > >work/complexity in creating a "framework" here where we probably don't
> > >need it.
> > >
> > >I'll give some more detailed responses on your individual patches, but
> > >at a high level I don't really see the need to treat color correction
> > >properties (csc, gamma, etc.) in a special way with their own
> > >registration framework.  There are really three things to consider here:
> > >  * How/where to create the properties
> > >  * How/where to attach properties to CRTC's and/or planes
> > >  * How to handle property changes
> > >
> > >For creating properties, at the moment you're doing that via
> > >intel_modeset_init() -> intel_clrmgr_init() ->
> > >intel_clrmgr_create_color_properties().  Presumably we'll add other
> > >(non-color correction) properties to the driver in the future, so it
> > >seems like it would be simpler if we just renamed your
> > >intel_clrmgr_create_color_properties() to something like
> > >intel_modeset_create_properties() and called it directly from
> > >intel_modeset_init().  I don't see the intermediate intel_clrmgr_init()
> > >adding any value at the moment, so I think it can be removed.
> > >
> > I got this point Matt, and we can do this. The only confusion I have
> > is, we already have places where we create properties, and if we are
> > intending to create different type of properties in this function,
> > would that align with the previous property creations places ?
> > 
> > At least we have a common ground among the color properties,  that's
> > why I am sticking them together.
> > 
> > If you dont like this, the other common ground is CRTC/plane
> > properties. These are the first of CRTC or plane properties.
> > So I can create a intel_create_crtc_properties()
> 
> We do actually have one plane property (rotation) now that just went
> into the driver.  But you're right that we also have connector
> properties that are handled a bit differently at the moment.  There are
> 'audio' and 'Broadcast RGB' properties that are stored in dev_priv and
> get created the first time they are attached to a connector.  Personally
> I don't see a problem with moving the creation of those two properties
> into your new intel_modeset_create_properties() function; it's not like
> we're using up a ton of memory in cases where we don't have any relevant
> connectors to attach them to.
> 
> We also have a whole bunch of SDVO/TV connector properties that are
> actually stored in the connector itself, which seems a bit off to me.
> Generally properties get stored in a central location like dev or
> dev_priv so that they can be shared between multiple objects.  I'm
> not really familiar with the SDVO code, so I'm not sure if there's some
> subtle reason the code was written this way or whether it's just really
> old code that nobody ever cleaned up (git blame does indicate that most
> of that logic is from 2009-2010).

Generally there's just one sdvo/tv-out connector, and the properties are
highly dynamic. We could refactor that, but just not worth it.

> I'd be inclined to move the audio and broadcast properties in alongside
> your new color property setup code (and just make it a generic property
> setup function as noted).  Same with the rotation plane property.  Since
> the SDVO/TV properties are a bit of a different world (and since I'm not
> personally familiar enough with it to feel comfortable touching it), I'd
> leave those as they are for now.  But if any of the OTC reviewers think
> differently, I'll defer to their judgment.

Hm, I don't care whether we do lazy&distributed or eager&central prop
creation. Imo the important part is that attaching the properties is done
where the objects get initialized and not in a central place, since I
don't see any value in that indirection. And having it per-object all
together should make it easier to adjust property-attachment for
platform-oddities ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 0/4] Color manager framework

[Sharma, Shashank]

Thanks Bob, Matt, Daniel for the review. 
I will create a new patch set, complying all (almost :)) review comments from you all, and will float for review. 

Points I noted down overall: 
1.  No need for separate arrays for names, sizes etc (:( )
2.  Create a _set_blob for blob_properties, and take that route for setting values of blob property in blob.
3.  Keep hue and saturation as separate properties, programming the same control register.
4.  Create a generic function _create_crtc/plane_property (instead of create_color_property), and create properties there. This function might go in intel_display.c or intel_modes.c (?) . 
5.  Move some of the existing property creation code in that function, if required.
6.  Attach the property to object while initializing the CRTC/plane.
7.  Keep gamma, brightness, contrast, hue, saturation in mode_config.
8.  CSC coeff might be different for big core and VLV, but still the property is valid, and can be configured. Also, I can see CSC specified in Tegra driver (linux for tegra code, csc.c) which suggests its more than us who might be interested. 
     So lets keep CSC also  in mode_config. 

Please let me know if this sounds ok, or you suggest modifications. 

Regards
Shashank

-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, September 11, 2014 1:27 PM
To: Roper, Matthew D
Cc: Sharma, Shashank; intel-gfx@lists.freedesktop.org; Vetter, Daniel
Subject: Re: [Intel-gfx] [PATCH 0/4] Color manager framework

On Wed, Sep 10, 2014 at 11:15:11AM -0700, Matt Roper wrote:
> On Wed, Sep 10, 2014 at 04:38:43PM +0530, Sharma, Shashank wrote:
> > Hello Matt,
> > 
> > Thanks for your detailed descriptions, reviews comments and time.
> > Please find my comments inline.
> > 
> > Regards
> > Shashank
> > On 9/10/2014 6:58 AM, Matt Roper wrote:
> > >On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sharma@intel.com wrote:
> > >>From: Shashank Sharma <shashank.sharma@intel.com>
> > >>
> > >>Color manager is an extention to i915 driver which provides 
> > >>display tuning and color-correction properties to user space, via 
> > >>DRM propery interface.Different Intel platforms support different 
> > >>color tuning capabilities which can be exploited using this framework.
> > >>
> > >>This patch set adds color correction for VLV, and the code is 
> > >>written in such a way that new color properties and support for 
> > >>other platforms can be pluggen in, using the same architecture.
> > >>
> > >>For the design discussion, right now only one color correction 
> > >>property (CSC) has been added. Once we agree on the design, 
> > >>gamma-correction, contrast, brightness, and hue/saturation would be followed by the same.
> > >>
> > >>What this patch set does, is:
> > >>1. Color manager framework for valleyview:
> > >>Add basic functions of framework, to create and destroy DRM 
> > >>properties for color correction. It also adds header, enums and defines.
> > >>
> > >>2. Plug-in color manager attach
> > >>Attach created color properties, with the objects. Basically 
> > >>properties get attached to two type of objects, crtc (pipe level correction) and plane (plane level correction).
> > >>
> > >>3. CSC color correction
> > >>First color correction method.
> > >>- Add color property for CSC during init.
> > >>- Add blob to keep correction values
> > >>- Attach DRM CSC propery with each CRTC object
> > >>- Core CSC correction for VLV
> > >>
> > >>4. Add set_property function for intel CRTC.
> > >>This function checks the type of the property, and calls the 
> > >>appropriate high level function (intel_clrmgr_set_csc), which does 
> > >>platform check and calls the core platform color correction 
> > >>function (vlv_set_csc)
> > >>
> > >>V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
> > >>- Creating only one property per color correction, and attaching it to every DRM object.
> > >>- No additional data structures on top of DRM property.
> > >>- No registeration of color property, just create and attach.
> > >>- Added properties in dev->mode_config
> > >
> > >Hi Shashank, thanks for incorporating the feedback from the last 
> > >review round.  This patchset is definitely moving in the right 
> > >direction, although I still feel that there's still a little bit of 
> > >unnecessary work/complexity in creating a "framework" here where we 
> > >probably don't need it.
> > >
> > >I'll give some more detailed responses on your individual patches, 
> > >but at a high level I don't really see the need to treat color 
> > >correction properties (csc, gamma, etc.) in a special way with 
> > >their own registration framework.  There are really three things to consider here:
> > >  * How/where to create the properties
> > >  * How/where to attach properties to CRTC's and/or planes
> > >  * How to handle property changes
> > >
> > >For creating properties, at the moment you're doing that via
> > >intel_modeset_init() -> intel_clrmgr_init() -> 
> > >intel_clrmgr_create_color_properties().  Presumably we'll add other 
> > >(non-color correction) properties to the driver in the future, so 
> > >it seems like it would be simpler if we just renamed your
> > >intel_clrmgr_create_color_properties() to something like
> > >intel_modeset_create_properties() and called it directly from 
> > >intel_modeset_init().  I don't see the intermediate 
> > >intel_clrmgr_init() adding any value at the moment, so I think it can be removed.
> > >
> > I got this point Matt, and we can do this. The only confusion I have 
> > is, we already have places where we create properties, and if we are 
> > intending to create different type of properties in this function, 
> > would that align with the previous property creations places ?
> > 
> > At least we have a common ground among the color properties,  that's 
> > why I am sticking them together.
> > 
> > If you dont like this, the other common ground is CRTC/plane 
> > properties. These are the first of CRTC or plane properties.
> > So I can create a intel_create_crtc_properties()
> 
> We do actually have one plane property (rotation) now that just went 
> into the driver.  But you're right that we also have connector 
> properties that are handled a bit differently at the moment.  There 
> are 'audio' and 'Broadcast RGB' properties that are stored in dev_priv 
> and get created the first time they are attached to a connector.  
> Personally I don't see a problem with moving the creation of those two 
> properties into your new intel_modeset_create_properties() function; 
> it's not like we're using up a ton of memory in cases where we don't 
> have any relevant connectors to attach them to.
> 
> We also have a whole bunch of SDVO/TV connector properties that are 
> actually stored in the connector itself, which seems a bit off to me.
> Generally properties get stored in a central location like dev or 
> dev_priv so that they can be shared between multiple objects.  I'm not 
> really familiar with the SDVO code, so I'm not sure if there's some 
> subtle reason the code was written this way or whether it's just 
> really old code that nobody ever cleaned up (git blame does indicate 
> that most of that logic is from 2009-2010).

Generally there's just one sdvo/tv-out connector, and the properties are highly dynamic. We could refactor that, but just not worth it.

> I'd be inclined to move the audio and broadcast properties in 
> alongside your new color property setup code (and just make it a 
> generic property setup function as noted).  Same with the rotation 
> plane property.  Since the SDVO/TV properties are a bit of a different 
> world (and since I'm not personally familiar enough with it to feel 
> comfortable touching it), I'd leave those as they are for now.  But if 
> any of the OTC reviewers think differently, I'll defer to their judgment.

Hm, I don't care whether we do lazy&distributed or eager&central prop creation. Imo the important part is that attaching the properties is done where the objects get initialized and not in a central place, since I don't see any value in that indirection. And having it per-object all together should make it easier to adjust property-attachment for platform-oddities ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 0/4] Color manager framework

[Daniel Vetter]

On Thu, Sep 11, 2014 at 10:18 AM, Sharma, Shashank
<shashank.sharma@intel.com> wrote:
> Thanks Bob, Matt, Daniel for the review.
> I will create a new patch set, complying all (almost :)) review comments from you all, and will float for review.
>
> Points I noted down overall:
> 1.  No need for separate arrays for names, sizes etc (:( )
> 2.  Create a _set_blob for blob_properties, and take that route for setting values of blob property in blob.

Please coordinate with Rob Clark/Ville on this, since the atomic ioctl
also needs a set_blob. I'm not sure whether they have this already
even. Adding them.

Also there's no need to block brightness/hue/... and such simpler
properties on this, so best to submit patches in parallel and
prioritize some of the simpler ones to get those in first.

> 3.  Keep hue and saturation as separate properties, programming the same control register.
> 4.  Create a generic function _create_crtc/plane_property (instead of create_color_property), and create properties there. This function might go in intel_display.c or intel_modes.c (?) .

intel_display.c sounds ok. Splitting that monster is an entire task in
itself, and atm no one has a good idea really ;-)

> 5.  Move some of the existing property creation code in that function, if required.

Not required imo, see my reply to Matt's mail.

> 6.  Attach the property to object while initializing the CRTC/plane.
> 7.  Keep gamma, brightness, contrast, hue, saturation in mode_config.
> 8.  CSC coeff might be different for big core and VLV, but still the property is valid, and can be configured. Also, I can see CSC specified in Tegra driver (linux for tegra code, csc.c) which suggests its more than us who might be interested.
>      So lets keep CSC also  in mode_config.

Cross-driver properties only make sense if they work the same
everywhere. Of course every gpu has some CSC control or even a matrix
somewhere, but they'll work differently on different platforms. Shared
properties (in mode_config) imo only make sense if a generic driver
can make sense of them (like xf86-video-modesetting has support for
the plane rotation stuff we've added).

> Please let me know if this sounds ok, or you suggest modifications.

Minor comments, but sounds good as a plan.
-Daniel

>
> Regards
> Shashank
>
> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, September 11, 2014 1:27 PM
> To: Roper, Matthew D
> Cc: Sharma, Shashank; intel-gfx@lists.freedesktop.org; Vetter, Daniel
> Subject: Re: [Intel-gfx] [PATCH 0/4] Color manager framework
>
> On Wed, Sep 10, 2014 at 11:15:11AM -0700, Matt Roper wrote:
>> On Wed, Sep 10, 2014 at 04:38:43PM +0530, Sharma, Shashank wrote:
>> > Hello Matt,
>> >
>> > Thanks for your detailed descriptions, reviews comments and time.
>> > Please find my comments inline.
>> >
>> > Regards
>> > Shashank
>> > On 9/10/2014 6:58 AM, Matt Roper wrote:
>> > >On Tue, Sep 09, 2014 at 11:53:12AM +0530, shashank.sharma@intel.com wrote:
>> > >>From: Shashank Sharma <shashank.sharma@intel.com>
>> > >>
>> > >>Color manager is an extention to i915 driver which provides
>> > >>display tuning and color-correction properties to user space, via
>> > >>DRM propery interface.Different Intel platforms support different
>> > >>color tuning capabilities which can be exploited using this framework.
>> > >>
>> > >>This patch set adds color correction for VLV, and the code is
>> > >>written in such a way that new color properties and support for
>> > >>other platforms can be pluggen in, using the same architecture.
>> > >>
>> > >>For the design discussion, right now only one color correction
>> > >>property (CSC) has been added. Once we agree on the design,
>> > >>gamma-correction, contrast, brightness, and hue/saturation would be followed by the same.
>> > >>
>> > >>What this patch set does, is:
>> > >>1. Color manager framework for valleyview:
>> > >>Add basic functions of framework, to create and destroy DRM
>> > >>properties for color correction. It also adds header, enums and defines.
>> > >>
>> > >>2. Plug-in color manager attach
>> > >>Attach created color properties, with the objects. Basically
>> > >>properties get attached to two type of objects, crtc (pipe level correction) and plane (plane level correction).
>> > >>
>> > >>3. CSC color correction
>> > >>First color correction method.
>> > >>- Add color property for CSC during init.
>> > >>- Add blob to keep correction values
>> > >>- Attach DRM CSC propery with each CRTC object
>> > >>- Core CSC correction for VLV
>> > >>
>> > >>4. Add set_property function for intel CRTC.
>> > >>This function checks the type of the property, and calls the
>> > >>appropriate high level function (intel_clrmgr_set_csc), which does
>> > >>platform check and calls the core platform color correction
>> > >>function (vlv_set_csc)
>> > >>
>> > >>V2: Re-designed based on review comments and suggestions from Matt Roper and Daniel.
>> > >>- Creating only one property per color correction, and attaching it to every DRM object.
>> > >>- No additional data structures on top of DRM property.
>> > >>- No registeration of color property, just create and attach.
>> > >>- Added properties in dev->mode_config
>> > >
>> > >Hi Shashank, thanks for incorporating the feedback from the last
>> > >review round.  This patchset is definitely moving in the right
>> > >direction, although I still feel that there's still a little bit of
>> > >unnecessary work/complexity in creating a "framework" here where we
>> > >probably don't need it.
>> > >
>> > >I'll give some more detailed responses on your individual patches,
>> > >but at a high level I don't really see the need to treat color
>> > >correction properties (csc, gamma, etc.) in a special way with
>> > >their own registration framework.  There are really three things to consider here:
>> > >  * How/where to create the properties
>> > >  * How/where to attach properties to CRTC's and/or planes
>> > >  * How to handle property changes
>> > >
>> > >For creating properties, at the moment you're doing that via
>> > >intel_modeset_init() -> intel_clrmgr_init() ->
>> > >intel_clrmgr_create_color_properties().  Presumably we'll add other
>> > >(non-color correction) properties to the driver in the future, so
>> > >it seems like it would be simpler if we just renamed your
>> > >intel_clrmgr_create_color_properties() to something like
>> > >intel_modeset_create_properties() and called it directly from
>> > >intel_modeset_init().  I don't see the intermediate
>> > >intel_clrmgr_init() adding any value at the moment, so I think it can be removed.
>> > >
>> > I got this point Matt, and we can do this. The only confusion I have
>> > is, we already have places where we create properties, and if we are
>> > intending to create different type of properties in this function,
>> > would that align with the previous property creations places ?
>> >
>> > At least we have a common ground among the color properties,  that's
>> > why I am sticking them together.
>> >
>> > If you dont like this, the other common ground is CRTC/plane
>> > properties. These are the first of CRTC or plane properties.
>> > So I can create a intel_create_crtc_properties()
>>
>> We do actually have one plane property (rotation) now that just went
>> into the driver.  But you're right that we also have connector
>> properties that are handled a bit differently at the moment.  There
>> are 'audio' and 'Broadcast RGB' properties that are stored in dev_priv
>> and get created the first time they are attached to a connector.
>> Personally I don't see a problem with moving the creation of those two
>> properties into your new intel_modeset_create_properties() function;
>> it's not like we're using up a ton of memory in cases where we don't
>> have any relevant connectors to attach them to.
>>
>> We also have a whole bunch of SDVO/TV connector properties that are
>> actually stored in the connector itself, which seems a bit off to me.
>> Generally properties get stored in a central location like dev or
>> dev_priv so that they can be shared between multiple objects.  I'm not
>> really familiar with the SDVO code, so I'm not sure if there's some
>> subtle reason the code was written this way or whether it's just
>> really old code that nobody ever cleaned up (git blame does indicate
>> that most of that logic is from 2009-2010).
>
> Generally there's just one sdvo/tv-out connector, and the properties are highly dynamic. We could refactor that, but just not worth it.
>
>> I'd be inclined to move the audio and broadcast properties in
>> alongside your new color property setup code (and just make it a
>> generic property setup function as noted).  Same with the rotation
>> plane property.  Since the SDVO/TV properties are a bit of a different
>> world (and since I'm not personally familiar enough with it to feel
>> comfortable touching it), I'd leave those as they are for now.  But if
>> any of the OTC reviewers think differently, I'll defer to their judgment.
>
> Hm, I don't care whether we do lazy&distributed or eager&central prop creation. Imo the important part is that attaching the properties is done where the objects get initialized and not in a central place, since I don't see any value in that indirection. And having it per-object all together should make it easier to adjust property-attachment for platform-oddities ...
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 0/4] Color manager framework

[Ville Syrjälä]

On Thu, Sep 11, 2014 at 10:49:01AM +0200, Daniel Vetter wrote:
> On Thu, Sep 11, 2014 at 10:18 AM, Sharma, Shashank
> <shashank.sharma@intel.com> wrote:
> > Thanks Bob, Matt, Daniel for the review.
> > I will create a new patch set, complying all (almost :)) review comments from you all, and will float for review.
> >
> > Points I noted down overall:
> > 1.  No need for separate arrays for names, sizes etc (:( )
> > 2.  Create a _set_blob for blob_properties, and take that route for setting values of blob property in blob.
> 
> Please coordinate with Rob Clark/Ville on this, since the atomic ioctl
> also needs a set_blob. I'm not sure whether they have this already
> even. Adding them.

I'm pretty sure I had the blob thing in my atomic code. Hmm, yeah I used
it to shovel the mode into the kernel.

> 
> Also there's no need to block brightness/hue/... and such simpler
> properties on this, so best to submit patches in parallel and
> prioritize some of the simpler ones to get those in first.

Yes, please pick one hardware knob at a time and come up with a sane way
to represent that as a property. Let's not make things more complicated
by trying to refactor the code too much or come up with fancy new
frameworks. Just one property at a time please.

As for designing the properties I'd like them to have these properties:
- hardware agnostic if possible, ie. multiple drivers should be able to
  expose the same property and the compositor should not have to know
  which driver it's talking to.
- precisely describe what transformation is done to the data so that
  the compositor could have a fair chance of doing the same
  transformation via GL when not using hardware planes

Obviously those may not always be possible, but we should at least try
to come up with something like that before giving up and just shoveling
some hardware specific magic number across.

-- 
Ville Syrjälä
Intel OTC