date:20160429

https://bugs.freedesktop.org/show_bug.cgi?id=95085

--- Comment #14 from Nicolai Hï¿½hnle  ---
I think I understand now where the bug is coming from, and I'm not sure if it's
a driver or an application bug :)

The trace uses glVertexAttribPointer instead of glVertexAttribIPointer to set
up a vertex element that will consumed by an uint GLSL variable. I kind of
suspect that that should be undefined behaviour, but I haven't found a
corresponding spec reference.

In any case, it looks like this causes different parts of the driver and the
various auxiliary tools to disagree about whether the element should be treated
as an int or as a float, and some conversion happens somewhere that makes it
all go wrong...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/3eb139d6/attachment.html>

[Bug 95085] Invalid sampling of second texture in fragment shader that have two samplers with different parameters.

https://bugs.freedesktop.org/show_bug.cgi?id=95085

Nicolai Hï¿½hnle  changed:

   What|Removed |Added

 Resolution|NOTOURBUG   |---
 Status|RESOLVED|REOPENED

--- Comment #13 from Nicolai Hï¿½hnle  ---
I spoke too soon. There seem to be several bugs here (one pointed out by Bas
Nieuwenhuizen), I'm going to investigate this again in more detail.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/f9710cd3/attachment.html>

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #7 from barneyman at gmx.de ---
Ok, understood. Didn't know that feature. I'll give it a try in the next days.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/ebcb6c99/attachment.html>

[PATCH v2 10/10] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 483 -
 1 file changed, 482 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 3aa22eb..4a2de8a 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -30,9 +30,14 @@

 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };

-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;

 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -118,6 +123,332 @@ static int select_render_basic_config(struct 
drm_i915_private *dev_priv)
return 0;
 }

+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271C), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272C), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274C), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275C), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253A4), 0x },
+   { _MMIO(0x2681C), 0x01F00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781C), 0x01F00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265A0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538C), 0x0030 },
+   { _MMIO(0x25384), 0xAA8A },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680C), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0C0701E0 },
+   { _MMIO(0x2780C), 0x000200A0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xAA86 },
+   { _MMIO(0x25420), 0x08320C83 },
+   { _MMIO(0x25424), 0x06820C83 },
+   { _MMIO(0x2541C), 0x },
+   { _MMIO(0x25428), 0x0C03 },
+};
+
+static int select_compute_basic_config(struct drm_i915_private *dev_priv)
+{
+   dev_priv->perf.oa.mux_regs =
+   mux_config_compute_basic;
+   dev_priv->perf.oa.mux_regs_len =
+   ARRAY_SIZE(mux_config_compute_basic);
+
+   dev_priv->perf.oa.b_counter_regs =
+   b_counter_config_compute_basic;
+   dev_priv->perf.oa.b_counter_regs_len =
+   ARRAY_SIZE(b_counter_config_compute_basic);
+
+   return 0;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681C), 0x3EB00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02AA },
+   { _MMIO(0x25404), 0x03FF },
+   { _MMIO(0x26800), 0x00142284 },
+   { _MMIO(0x26808), 0x0E629062 },
+   { _MMIO(0x2680C), 0x3F6F55CB },
+   { _MMIO(0x26810), 0x0014 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x26104), 0x02AA },
+   { _MMIO(0x26184), 0x02AA },
+   { _MMIO(0x25420), 0x

[PATCH v2 09/10] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 42 
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3789378..045ffe8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -71,6 +71,23 @@ static u32 i915_perf_stream_paranoid = true;
  */
 #define OA_EXPONENT_MAX 31

+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int zero;
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1229,21 +1246,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}

-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}

@@ -1305,6 +1314,15 @@ static struct ctl_table oa_table[] = {
 .mode = 0644,
 .proc_handler = proc_dointvec,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = &i915_oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = &zero,
+.extra2 = &oa_exponent_max,
+},
{}
 };

-- 
2.7.1

[PATCH v2 08/10] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 46 +++-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 68fdf1a..91a88fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,7 @@ struct drm_i915_private {
bool initialized;

struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;

struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ef0a240..3789378 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -59,6 +59,8 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)

+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1084,7 +1086,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev,
}
}

-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1288,6 +1296,38 @@ int i915_perf_open_ioctl(struct drm_device *dev, void 
*data,
return ret;
 }

+
+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = &i915_perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1333,6 +1373,8 @@ void i915_perf_init(struct drm_device *dev)
return;
}

+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;

return;
@@ -1345,6 +1387,8 @@ void i915_perf_fini(struct drm_device *dev)
if (!dev_priv->perf.initialized)
return;

+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
i915_perf_deinit_sysfs_hsw(dev_priv);

kobject_put(dev_priv->perf.metrics_kobj);
-- 
2.7.1

[PATCH v2 07/10] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit configuration that can be reliably used as a key to
lookup corresponding counter meta data and normalization equations.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 45 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 
 drivers/gpu/drm/i915/i915_perf.c   | 18 ++-
 4 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 602eb03..68fdf1a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2097,6 +2097,8 @@ struct drm_i915_private {
struct {
bool initialized;

+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 5472aa0..3aa22eb 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */

+#include 
+
 #include "i915_drv.h"

 enum metric_set_id {
@@ -130,3 +132,46 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   &dev_attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int ret;
+
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
&group_render_basic);
+   if (ret)
+   goto error_render_basic;
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, &group_render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..e4ba89d 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h
@@ -31,4 +31,8 @@ extern int i915_oa_n_builtin_metric_sets_hsw;

 extern int i915_oa_select_metric_set_hsw(struct drm_i915_private *dev_priv);

+extern int i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv);
+
+extern void i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv);
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 094c6ed..ef0a240 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1295,6 +1295,11 @@ void i915_perf_init(struct drm_device *dev)
if (!IS_HASWELL(dev))
return;

+   dev_priv->perf.metrics_kobj =
+   kobject_create_and_add("metrics", &dev->primary->kdev->kobj);
+   if (!dev_priv->perf.metrics_kobj)
+   return;
+
hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
 CLOCK_MONOTONIC, HRTIMER_MODE_REL);
dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
@@ -1322,9 +1327,15 @@ void i915_perf_init(struct drm_device *dev)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;

-   dev_priv->perf.oa.oa_formats = hsw_oa_formats;
+   if (i915_perf_init_sysfs_hsw(dev_priv)) {
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+   return;
+   }

dev_priv->perf.initialized = true;
+
+   return;
 }

 void i915_perf_fini(struct drm_device *dev)
@@ -1334,6 +1345,11 @@ void i915_perf_fini(struct drm_device *dev)
if (!dev_priv->perf.initialized)
return;

+   i915_perf_deinit_sysfs_hsw(dev_priv);
+
+   kobject_put(dev_priv->perf.metrics_kobj);
+   dev_priv->perf.metrics_kobj = NULL;
+
dev_priv->perf.oa.ops.init_oa_buffer = NULL;

dev_priv->perf.initialized = false;
-- 
2.7.1

[PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |  56 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
 drivers/gpu/drm/i915/i915_perf.c| 931 +++-
 drivers/gpu/drm/i915/i915_reg.h | 338 
 include/uapi/drm/i915_drm.h |  70 ++-
 5 files changed, 1399 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f85fd72..602eb03 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1712,6 +1712,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
i915_reg_t addr;
u32 value;
@@ -1789,11 +1794,26 @@ struct i915_perf_stream {
struct list_head link;

u32 sample_flags;
+   int sample_size;

struct intel_context *ctx;
bool enabled;

-   struct i915_perf_stream_ops *ops;
+   const struct i915_perf_stream_ops *ops;
+};
+
+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   struct i915_perf_read_state *read_state);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };

 struct drm_i915_private {
@@ -2076,16 +2096,46 @@ struct drm_i915_private {

struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;

+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;

const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct drm_i915_gem_object *obj;
+   u32 gtt_offset;
+   u8 *addr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;

@@ -3441,6 +3491,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,

 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
+void i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+   struct intel_context *context);

 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index b1b704c..4fec631 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -135,6 +135,23 @@ static int get_context_size(struct drm_device *dev)
return ret;
 }

+static int i915_gem_context_pin_state(struct drm_device *dev,
+ struct intel_context *ctx)
+{
+   int ret;
+
+   BUG_ON(!mutex_is_locked(&dev->struct_mutex));
+
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev), 0);
+   if (ret)
+   return ret;
+
+   i915_oa_context_pin_notify(dev->dev_private, ctx);
+
+   return 0;
+}
+
 static void i915_gem_context_clean(struct intel_context *ctx)
 {
struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
@@ -319,8 +336,7 @@ i915_gem_c

[PATCH v2 05/10] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is autogenerated from an internal XML
description of metric sets.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h|  14 
 drivers/gpu/drm/i915/i915_oa_hsw.c | 132 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  34 ++
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d90d907..5293fc7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -100,7 +100,8 @@ i915-y += dvo_ch7017.o \
 i915-y += i915_vgpu.o

 # perf code
-i915-y += i915_perf.o
+i915-y += i915_perf.o \
+ i915_oa_hsw.o

 # legacy horrors
 i915-y += i915_dma.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d2450f..f85fd72 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1712,6 +1712,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_oa_reg {
+   i915_reg_t addr;
+   u32 value;
+};
+
 struct i915_perf_read_state {
int count;
ssize_t read;
@@ -2073,6 +2078,15 @@ struct drm_i915_private {
bool initialized;
struct mutex lock;
struct list_head streams;
+
+   struct {
+   u32 metrics_set;
+
+   const struct i915_oa_reg *mux_regs;
+   int mux_regs_len;
+   const struct i915_oa_reg *b_counter_regs;
+   int b_counter_regs_len;
+   } oa;
} perf;

/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
new file mode 100644
index 000..5472aa0
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -0,0 +1,132 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 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.
+ *
+ */
+
+#include "i915_drv.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_hsw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2710), 0x },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x253A4), 0x0160 },
+   { _MMIO(0x25440), 0x0010 },
+   { _MMIO(0x25128), 0x },
+   { _MMIO(0x2691C), 0x0800 },
+   { _MMIO(0x26AA0), 0x0150 },
+   { _MMIO(0x26B9C), 0x6000 },
+   { _MMIO(0x2791C), 0x0800 },
+   { _MMIO(0x27AA0), 0x0150 },
+   { _MMIO(0x27B9C), 0x6000 },
+   { _MMIO(0x2641C), 0x0400 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538C), 0x },
+   { _MMIO(0x25384), 0x0800 },
+   { _MMIO(0x25400), 0x0004 },
+   { _MMIO(0x2540C), 0x06029000 },
+   { _MMIO(0x25410), 0x0002 },
+   { _MMIO(0x25404), 0x5C30 },
+   { _MMIO(0x25100), 0x0016 },
+   { _MMIO(0x25110), 0x0400 },
+   { _MMIO(0x25104), 0x },
+   { _MMIO(0x26804), 0x1211 },
+   { _MMIO(0x26884), 0x0100 },
+   { _MMIO(0x26900), 0x0002 },
+   { _MMIO(0x26908), 0x0070 },
+   { _MMIO(0x26904), 0x },
+   { _MMIO(0x26984), 0x1022 },
+   { _MMIO(0x26A04), 0x0011 },
+   { _MMIO(0x26A80), 0x0006 },
+   { _MMIO(0x26A88), 0x0C02 },
+   { _MMIO(0x26A84), 0x000

[PATCH v2 04/10] drm/i915: don't whitelist oacontrol in cmd parser

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 33 ++---
 1 file changed, 2 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5724d80..ff2b57b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -445,7 +445,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1044,8 +1043,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs *engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_REJECT) {
DRM_DEBUG_DRIVER("CMD: Rejected command: 0x%08X\n", *cmd);
@@ -1083,26 +1081,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}

/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1186,7 +1164,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
 {
u32 *cmd, *batch_base, *batch_end;
struct drm_i915_cmd_descriptor default_desc = { 0 };
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
int ret = 0;

batch_base = copy_batch(shadow_batch_obj, batch_obj,
@@ -1243,8 +1220,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
break;
}

-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  &oacontrol_set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EACCES;
break;
}
@@ -1252,11 +1228,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine,
cmd += length;
}

-   if (oacontrol_set) {
-   DRM_DEBUG_DRIVER("CMD: batch set OACONTROL but did not clear 
it\n");
-   ret = -EINVAL;
-   }
-
if (cmd >= batch_end) {
DRM_DEBUG_DRIVER("CMD: Got to the end of the buffer w/o a BBE 
cmd!\n");
ret = -

[PATCH v2 03/10] drm/i915: return EACCES for check_cmd() failures

check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.

The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.

In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.

In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).

As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 035f2dd..5724d80 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1245,7 +1245,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine,

if (!check_cmd(engine, desc, cmd, length, is_master,
   &oacontrol_set)) {
-   ret = -EINVAL;
+   ret = -EACCES;
break;
}

-- 
2.7.1

[PATCH v2 02/10] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index a337f33..035f2dd 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -445,7 +445,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1092,7 +1092,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a2fd30..11eccf4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -611,7 +611,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)

-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)

 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.7.1

[PATCH v2 01/10] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_dma.c  |   8 +
 drivers/gpu/drm/i915/i915_drv.h  |  92 +
 drivers/gpu/drm/i915/i915_perf.c | 431 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 601 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 723c502..d90d907 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -99,6 +99,9 @@ i915-y += dvo_ch7017.o \
 # virtual gpu code
 i915-y += i915_vgpu.o

+# perf code
+i915-y += i915_perf.o
+
 # legacy horrors
 i915-y += i915_dma.o

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f69330c..89cec21 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1074,6 +1074,11 @@ static int i915_driver_init_early(struct 
drm_i915_private *dev_priv,
if (ret < 0)
return ret;

+   /* Must at least be initialized before trying to pin any context
+* which i915_perf hooks into.
+*/
+   i915_perf_init(dev);
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev);

@@ -1460,6 +1465,8 @@ int i915_driver_unload(struct drm_device *dev)

i915_driver_unregister(dev_priv);

+   i915_perf_fini(dev);
+
drm_vblank_cleanup(dev);

intel_modeset_cleanup(dev);
@@ -1611,6 +1618,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };

 int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2abbcc..3d2450f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1712,6 +1712,85 @@ struct intel_wm_config {
bool sprites_scaled;
 };

+struct i915_perf_read_state {
+   int count;
+   ssize_t read;
+   char __user *buf;
+};
+
+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_stream *stream,
+ struct file *file,
+ poll_table *wait);
+
+   /* For handling a blo

[PATCH v2 00/10] Enable Gen 7 Observation Architecture

Hopefully covers the last issues raised by Chris and addresses the open issue I
had with removing OACONTROL from the command parser whitelist.

- Robert

Robert Bragg (10):
  drm/i915: Add i915 perf infrastructure
  drm/i915: rename OACONTROL GEN7_OACONTROL
  drm/i915: return EACCES for check_cmd() failures
  drm/i915: don't whitelist oacontrol in cmd parser
  drm/i915: Add 'render basic' Haswell OA unit config
  drm/i915: Enable i915 perf stream for Haswell OA unit
  drm/i915: advertise available metrics via sysfs
  drm/i915: Add dev.i915.perf_event_paranoid sysctl option
  drm/i915: add oa_event_min_timer_exponent sysctl
  drm/i915: Add more Haswell OA metric sets

 drivers/gpu/drm/i915/Makefile   |4 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |   35 +-
 drivers/gpu/drm/i915/i915_dma.c |8 +
 drivers/gpu/drm/i915/i915_drv.h |  161 
 drivers/gpu/drm/i915/i915_gem_context.c |   24 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c  |  658 ++
 drivers/gpu/drm/i915/i915_oa_hsw.h  |   38 +
 drivers/gpu/drm/i915/i915_perf.c| 1418 +++
 drivers/gpu/drm/i915/i915_reg.h |  340 +++-
 include/uapi/drm/i915_drm.h |  133 +++
 10 files changed, 2781 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

-- 
2.7.1

[Bug 95085] Invalid sampling of second texture in fragment shader that have two samplers with different parameters.

https://bugs.freedesktop.org/show_bug.cgi?id=95085

Nicolai Hï¿½hnle  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #12 from Nicolai Hï¿½hnle  ---
Frankly, I don't see how your sample is supposed to render text. The fragment
shader only accesses the font texture when nModeOut != 0u, and the value is
just passed through from the vertex buffer. According to qapitrace, nModeIn is
equal to 0 for all vertices in the final glDrawArrays call... at least based on
the apitrace, I'm pretty sure that this is not a driver bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/fc204e1c/attachment-0001.html>

[RFC v2 5/8] drm/fence: add in-fences support

2016-04-29 Thread Rob Clark

On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone  wrote:
> Hi,
>
> On 28 April 2016 at 23:28, Rob Clark  wrote:
>> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter  wrote:
>>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
 A (per-CRTC?) array of fences would be more flexible.  And even in the 
 cases
 where you could make a 1-to-1 mapping between planes and fences, it's not
 that much more work for userspace to assemble those fences into an array
 anyway.
>>>
>>> I'm ok with an array too if that's what you folks prefer (it's meant to be
>>> used by you after all). I just don't want just 1 fence for the entire op,
>>> forcing userspace to first merge them all together. That seems silly.
>>
>> I was kinda more a fan of array too, if for no other reason that to be
>> consistent w/ how out-fences work.  (And using property just for
>> in-fence seemed slightly weird/abusive to me)
>
> I don't think it's really useful to look for much consistency between
> the two, beyond the name. I'm more concerned with consistency between
> in-fences and the implicit fences on buffers/FBs, and between
> out-fences and the page_flip_events.
>
>>> One side-effect of that is that we'd also have to rework all the internal
>>> bits and move fences around in atomic. Which means change a pile of
>>> drivers. Not sure that's worth it, but I'd be ok either way really.
>>
>> hmm, well we could keep the array per-plane (and if one layer is using
>> multiple planes, just list the same fd multiple times).. then it
>> mostly comes down to changes in the ioctl fxn itself.
>
> ... and new API in libdrm, which is going to be a serious #ifdef and
> distribution pain. The core property API has been available since
> 2.4.62 last June, but for this we'd have to write the code, wait for
> the kernel code, wait for HWC, get everything together, and then merge
> and release. That gives minimum one year of libdrm releases which have
> had atomic but not in-fence API support, if we're adding a new array.
> And I just don't really see what it buys us, apart from the need for
> the core atomic_get_property helper to statically return -1 when
> requesting FENCE_FD.

don't we have the same issue for out-fences anyway?

ofc, I suspect we could handle making fences look like properties in
userspace in libdrm (at least if there was a sane way that libdrm
could track and eventually close() old out-fence fd's).  I'm not
entirely sure this matters, I mean how do we make implicit vs explicit
fencing transparent to the compositor and the proto between
compositor<->app?

Admittedly I haven't given *too* much thought yet about the
implications to libdrm and it's users, but it seems like we need to
make a v2 API rev anyway for out-fences, and the compositor is going
to need different codepaths for explicit vs implicit (if it supports
both).  So I don't think in-fences as something other than property
really costs us anything additional?

(Unless there is some sane reason to have an intermediate state w/
in-fences but pageflip events instead of out-fences?  But that seems
odd..)

BR,
-R


> Cheers,
> Daniel

[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support


On 29/04/16 17:55, Daniel Vetter wrote:

>> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
>> That sounds like a very bad idea to me...
>>
>> If this is only for accumulating changes, I think it may be better to
>> leave that to the driver as it may have better idea of how to accumulate.
>>
>> But, of course, this is a helper, so if all the drivers use this kind of
>> accumulation, it makes sense =).
> 
> Apparently panic context and cursor timer and stuff like that. I think
> this started with udl, and just to make sure (it's fbdev after all, no one
> wants to read the code itself) we've put those checks onto all entry
> points that draw stuff. It could be overkill, but this is what udl/qxl
> already do, so better to keep imo for now.
> 
> I guess if it's really not needed we could later on change that, but not
> sure that's worth the effort. And we can't get rid of it entirely.

Yep... Sounds fine to me.

Someone should implement (minimal) fbdev userspace API support to DRM
without using the current fbdev, and implement fbcon on top of that. I
don't like how DRM and fbdev gets mixed...

I offer a beer to anyone who does that =).

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/4c609073/attachment.sig>

[Bug 95103] [radeonsi] Blue-ish textures in many OpenGL games

https://bugs.freedesktop.org/show_bug.cgi?id=95103

kilobug  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from kilobug  ---
I just tried latest mesa git, and the bug did disappear, so it very likely was
the same issue than https://bugs.freedesktop.org/show_bug.cgi?id=95071

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/50c4815d/attachment-0001.html>

[PATCH v2 00/13] De-stage Sync File Framework

2016-04-29 Thread Greg Kroah-Hartman

On Thu, Apr 28, 2016 at 10:46:47AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> This patchset sits on top of Sync ABI Rework v13:
> 
> https://www.spinics.net/lists/dri-devel/msg105667.html
> 
> The first eight clean up and prepare sync_file for de-staging. The last four
> patches do the de-staging, moving files to drivers/dma-buf/ and include/linux/
> plus adding Documentation.
> 
> As the de-stage depends upon many changes on the staging tree it would
> be good to get all the patches merged through the staging tree if Sumit
> agrees with that.
> 
> The next step on the Sync de-stage is clean up the remaining bits
> of the Sync Framework, mainly SW_SYNC, which is only used for testing.
> 
> v2: - Add Reviewed-by: tag from Daniel Vetter to all patches.
> - Take in sugestions for the Sync File Documentation (Daniel)
> - Remove name arg from sync_file_crate() (Daniel)
> - Revome leftover EXPORT_SYMBOL(sync_file_merge) (Daniel)

Thanks for sticking with this, both series of patches are now applied,
thanks.

greg k-h

[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

Adding David, forgot that before hitting send.
-Daniel

On Fri, Apr 29, 2016 at 5:36 PM, Daniel Vetter  wrote:
> On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote:
>>
>> On 29/04/16 17:55, Daniel Vetter wrote:
>>
>> >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
>> >> That sounds like a very bad idea to me...
>> >>
>> >> If this is only for accumulating changes, I think it may be better to
>> >> leave that to the driver as it may have better idea of how to accumulate.
>> >>
>> >> But, of course, this is a helper, so if all the drivers use this kind of
>> >> accumulation, it makes sense =).
>> >
>> > Apparently panic context and cursor timer and stuff like that. I think
>> > this started with udl, and just to make sure (it's fbdev after all, no one
>> > wants to read the code itself) we've put those checks onto all entry
>> > points that draw stuff. It could be overkill, but this is what udl/qxl
>> > already do, so better to keep imo for now.
>> >
>> > I guess if it's really not needed we could later on change that, but not
>> > sure that's worth the effort. And we can't get rid of it entirely.
>>
>> Yep... Sounds fine to me.
>>
>> Someone should implement (minimal) fbdev userspace API support to DRM
>> without using the current fbdev, and implement fbcon on top of that. I
>> don't like how DRM and fbdev gets mixed...
>>
>> I offer a beer to anyone who does that =).
>
> The big plan that has been floated years back already (before David
> Herrmann disappeared into the rh systemd gang) was to have a pure
> userspace kmscon for console (including vt-switching in userspace like X
> does), plus a super-minimal panic console on top of kms in the kernel.
> That looked like a really solid design, unfornutately it didn't go
> anywhere. But basic patches are still around, and it really just boils
> down to that some distro would need to integrate kmscon properly, and
> polish of the kernel side too for integration.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



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

[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

On Fri, Apr 29, 2016 at 06:00:18PM +0300, Tomi Valkeinen wrote:
> 
> On 29/04/16 17:55, Daniel Vetter wrote:
> 
> >> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
> >> That sounds like a very bad idea to me...
> >>
> >> If this is only for accumulating changes, I think it may be better to
> >> leave that to the driver as it may have better idea of how to accumulate.
> >>
> >> But, of course, this is a helper, so if all the drivers use this kind of
> >> accumulation, it makes sense =).
> > 
> > Apparently panic context and cursor timer and stuff like that. I think
> > this started with udl, and just to make sure (it's fbdev after all, no one
> > wants to read the code itself) we've put those checks onto all entry
> > points that draw stuff. It could be overkill, but this is what udl/qxl
> > already do, so better to keep imo for now.
> > 
> > I guess if it's really not needed we could later on change that, but not
> > sure that's worth the effort. And we can't get rid of it entirely.
> 
> Yep... Sounds fine to me.
> 
> Someone should implement (minimal) fbdev userspace API support to DRM
> without using the current fbdev, and implement fbcon on top of that. I
> don't like how DRM and fbdev gets mixed...
> 
> I offer a beer to anyone who does that =).

The big plan that has been floated years back already (before David
Herrmann disappeared into the rh systemd gang) was to have a pure
userspace kmscon for console (including vt-switching in userspace like X
does), plus a super-minimal panic console on top of kms in the kernel.
That looked like a really solid design, unfornutately it didn't go
anywhere. But basic patches are still around, and it really just boils
down to that some distro would need to integrate kmscon properly, and
polish of the kernel side too for integration.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v4 4/7] fbdev: fb_defio: Export fb_deferred_io_mmap

On 28/04/16 18:18, Noralf TrÃ¸nnes wrote:
> Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
> When the framebuffer memory is allocated using dma_alloc_writecombine()
> instead of vmalloc(), I get cache syncing problems on ARM.
> This solves it:
> 
> static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> struct vm_area_struct *vma)
> {
>   fb_deferred_io_mmap(info, vma);
>   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> 
>   return 0;
> }
> 
> Could this have been done in the core?
> Drivers that don't set (struct fb_ops *)->fb_mmap, gets a call to
> fb_pgprotect() at the end of the default fb_mmap implementation
> (drivers/video/fbdev/core/fbmem.c). This is an architecture specific
> function that on many platforms uses pgprot_writecombine(), but not on
> all. And looking at some of the fb_mmap implementations, some of them
> sets vm_page_prot to nocache for instance, so I think the safest bet is
> to do this in the driver and not in the fbdev core. And we can't call
> fb_pgprotect() from fb_deferred_io_mmap() either because we don't have
> access to the file pointer that powerpc needs.
> 
> Signed-off-by: Noralf TrÃ¸nnes 

Acked-by: Tomi Valkeinen 

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/ca9134ae/attachment-0001.sig>

[PATCH v4 0/7] drm: Add fbdev deferred io support to helpers

On Thu, Apr 28, 2016 at 05:18:30PM +0200, Noralf TrÃ¸nnes wrote:
> This patchset adds fbdev deferred io support to drm_fb_helper and
> drm_fb_cma_helper.
> 
> It channels fbdev mmap and fb_{write,fillrect,copyarea,imageblit} damage
> through the (struct drm_framebuffer_funcs)->dirty callback on the
> fb_helper framebuffer which will always run in process context.
> 
> I have also added patches that converts qxl and udl to use this
> deferred io support. I have only compile tested it, no functional testing.
> I know that qxl is purely a software thing so I could actually test it, but
> I have never used qemu so I'm not keen on spending a lot of time on that.
> 
> This was originally part of the tinydrm patchset.
> 
> Changes since v3:
> - drm/fb-helper: Add fb_deferred_io support
>   - Don't use forward decl, move drm_fb_helper_dirty_work()
>   - Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
> 
> Changes since v2:
> - drm/rect: Add some drm_clip_rect utility functions
>   - This patch is dropped
> - drm/fb-helper: Add fb_deferred_io support
>   - FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
>   - The drm_clip_rect utility functions are dropped, so open code it
>   - docs: use & to denote structs
> - drm/qxl: Use drm_fb_helper deferred_io support
>   - The drm_clip_rect_{width/height} functions are dropped, so open code it
> 
> Changes since v1:
> - drm/fb-helper: Add fb_deferred_io support
>   - Use a dedicated worker to run the framebuffer flushing like qxl does
>   - Add parameter descriptions to drm_fb_helper_deferred_io
> - fbdev: fb_defio: Export fb_deferred_io_mmap
>   - Expand commit message
> - drm/qxl: Use drm_fb_helper deferred_io support
>   - Add FIXME about special dirty() callback for fbdev
>   - Remove note in commit message about deferred worker, drm_fb_helper
> is similar to qxl now.
> - drm/udl: Use drm_fb_helper deferred_io support
>   - No need to enable deferred_io by default since drm_fb_helper uses
> a dedicated worker for flushing
> 
> Changes since RFC:
> - Fix drm_clip_rect use to be exclusive on x2/y2
> - Put drm_clip_rect functions in drm_rect.{h,c}
> - Take into account that (struct fb_ops *)->fb_{write,...}() can be called
>   from atomic context (spin_lock_irqsave)
> - Export fb_deferred_io_mmap()
> - Add some more documentation
> - Add qxl and udl patches
> 
> Noralf TrÃ¸nnes (7):
>   drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
>   drm/qxl: Change drm_fb_helper_sys_*() calls to sys_*()
>   drm/fb-helper: Add fb_deferred_io support
>   fbdev: fb_defio: Export fb_deferred_io_mmap
>   drm/fb-cma-helper: Add fb_deferred_io support
>   drm/qxl: Use drm_fb_helper deferred_io support
>   drm/udl: Use drm_fb_helper deferred_io support

Scrolled through them all once more, and didn't spot anything else. Great
work! I plan to pull it all into drm-misc next week for 4.7 still. Please
ping me in case I forget.
-Daniel

> 
>  drivers/gpu/drm/Kconfig |   1 +
>  drivers/gpu/drm/drm_fb_cma_helper.c | 178 ++--
>  drivers/gpu/drm/drm_fb_helper.c | 103 -
>  drivers/gpu/drm/qxl/qxl_display.c   |   9 +-
>  drivers/gpu/drm/qxl/qxl_drv.h   |   7 +-
>  drivers/gpu/drm/qxl/qxl_fb.c| 223 
> +---
>  drivers/gpu/drm/qxl/qxl_kms.c   |   4 -
>  drivers/gpu/drm/udl/udl_drv.h   |   2 -
>  drivers/gpu/drm/udl/udl_fb.c| 140 +-
>  drivers/video/fbdev/core/fb_defio.c |   3 +-
>  include/drm/drm_fb_cma_helper.h |  14 +++
>  include/drm/drm_fb_helper.h |  15 +++
>  include/linux/fb.h  |   1 +
>  13 files changed, 372 insertions(+), 328 deletions(-)
> 
> --
> 2.2.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

On Fri, Apr 29, 2016 at 03:50:40PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> On 28/04/16 18:18, Noralf TrÃ¸nnes wrote:
> > This adds deferred io support to drm_fb_helper.
> > The fbdev framebuffer changes are flushed using the callback
> > (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
> > ensuring that it always runs in process context.
> > 
> > Signed-off-by: Noralf TrÃ¸nnes 
> > Reviewed-by: Daniel Vetter 
> > ---
> 
> Thanks for the series! Unfortunately I haven't been able to follow the
> discussions properly, so I hope my questions haven't been covered earlier.
> 
> > Changes since v3:
> > - Don't use forward decl, move drm_fb_helper_dirty_work()
> > - Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
> > 
> > Changes since v2:
> > - FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
> > - The drm_clip_rect utility functions are dropped, so open code it
> > - docs: use & to denote structs
> > 
> > Changes since v1:
> > - Use a dedicated worker to run the framebuffer flushing like qxl does
> > - Add parameter descriptions to drm_fb_helper_deferred_io
> > 
> >  drivers/gpu/drm/Kconfig |   1 +
> >  drivers/gpu/drm/drm_fb_helper.c | 103 
> > +++-
> >  include/drm/drm_fb_helper.h |  15 ++
> >  3 files changed, 118 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 9e4f2f1..8e6f34b 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -52,6 +52,7 @@ config DRM_KMS_FB_HELPER
> > select FB_CFB_FILLRECT
> > select FB_CFB_COPYAREA
> > select FB_CFB_IMAGEBLIT
> > +   select FB_DEFERRED_IO
> > help
> >   FBDEV helpers for KMS drivers.
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 855108e..62f849f 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -84,6 +84,15 @@ static LIST_HEAD(kernel_fb_helper_list);
> >   * and set up an initial configuration using the detected hardware, drivers
> >   * should call drm_fb_helper_single_add_all_connectors() followed by
> >   * drm_fb_helper_initial_config().
> > + *
> > + * If CONFIG_FB_DEFERRED_IO is enabled and &drm_framebuffer_funcs ->dirty 
> > is
> > + * set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit}
> > + * functions will accumulate changes and schedule &fb_helper .dirty_work 
> > to run
> > + * right away. This worker then calls the dirty() function ensuring that it
> > + * will always run in process context since the fb_*() function could be
> > + * running in atomic context. If drm_fb_helper_deferred_io() is used as the
> 
> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
> That sounds like a very bad idea to me...
> 
> If this is only for accumulating changes, I think it may be better to
> leave that to the driver as it may have better idea of how to accumulate.
> 
> But, of course, this is a helper, so if all the drivers use this kind of
> accumulation, it makes sense =).

Apparently panic context and cursor timer and stuff like that. I think
this started with udl, and just to make sure (it's fbdev after all, no one
wants to read the code itself) we've put those checks onto all entry
points that draw stuff. It could be overkill, but this is what udl/qxl
already do, so better to keep imo for now.

I guess if it's really not needed we could later on change that, but not
sure that's worth the effort. And we can't get rid of it entirely.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 95026] Alien Isolation segfault after initial loading screen/video

https://bugs.freedesktop.org/show_bug.cgi?id=95026

Nicolai Hï¿½hnle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #15 from Nicolai Hï¿½hnle  ---
commit 98c348d26b28a662d093543ecb7ca839e7883e8e

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/fd069c17/attachment.html>

[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire

https://bugs.freedesktop.org/show_bug.cgi?id=95133

Nicolai Hï¿½hnle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/0c562666/attachment.html>

[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

2016-04-29 Thread Noralf Trønnes


Den 29.04.2016 14:50, skrev Tomi Valkeinen:
> Hi,
>
> On 28/04/16 18:18, Noralf TrÃ¸nnes wrote:
>> This adds deferred io support to drm_fb_helper.
>> The fbdev framebuffer changes are flushed using the callback
>> (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
>> ensuring that it always runs in process context.
>>
>> Signed-off-by: Noralf TrÃ¸nnes 
>> Reviewed-by: Daniel Vetter 
>> ---
> Thanks for the series! Unfortunately I haven't been able to follow the
> discussions properly, so I hope my questions haven't been covered earlier.
>
>> Changes since v3:
>> - Don't use forward decl, move drm_fb_helper_dirty_work()
>> - Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
>>
>> Changes since v2:
>> - FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
>> - The drm_clip_rect utility functions are dropped, so open code it
>> - docs: use & to denote structs
>>
>> Changes since v1:
>> - Use a dedicated worker to run the framebuffer flushing like qxl does
>> - Add parameter descriptions to drm_fb_helper_deferred_io
>>
>>   drivers/gpu/drm/Kconfig |   1 +
>>   drivers/gpu/drm/drm_fb_helper.c | 103 
>> +++-
>>   include/drm/drm_fb_helper.h |  15 ++
>>   3 files changed, 118 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 9e4f2f1..8e6f34b 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -52,6 +52,7 @@ config DRM_KMS_FB_HELPER
>>  select FB_CFB_FILLRECT
>>  select FB_CFB_COPYAREA
>>  select FB_CFB_IMAGEBLIT
>> +select FB_DEFERRED_IO
>>  help
>>FBDEV helpers for KMS drivers.
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 855108e..62f849f 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -84,6 +84,15 @@ static LIST_HEAD(kernel_fb_helper_list);
>>* and set up an initial configuration using the detected hardware, drivers
>>* should call drm_fb_helper_single_add_all_connectors() followed by
>>* drm_fb_helper_initial_config().
>> + *
>> + * If CONFIG_FB_DEFERRED_IO is enabled and &drm_framebuffer_funcs ->dirty is
>> + * set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit}
>> + * functions will accumulate changes and schedule &fb_helper .dirty_work to 
>> run
>> + * right away. This worker then calls the dirty() function ensuring that it
>> + * will always run in process context since the fb_*() function could be
>> + * running in atomic context. If drm_fb_helper_deferred_io() is used as the
> Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
> That sounds like a very bad idea to me...

I haven't verified it myself, but took it as fact based on
commit: bcb39af4486be07e896fc374a2336bad3104ae0a

drm/udl: make usage as a console safer
Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later, the next printk
should cause it to appear. This isn't ideal, but it is simple, and seems to
work okay in my testing here.

(dirty area idea came from xenfb)

fixes a bunch of sleeping while atomic issues running fbcon on udl devices.

Cc: stable at vger.kernel.org
Signed-off-by: Dave Airlie 

> If this is only for accumulating changes, I think it may be better to
> leave that to the driver as it may have better idea of how to accumulate.
>
> But, of course, this is a helper, so if all the drivers use this kind of
> accumulation, it makes sense =).

qxl already accumulates damage this way and upcoming tinydrm also.
udl has handled this damage inline except when in_atomic() which results
in damage being deferred to the next fb_*() call.

It is possible for drivers to have their own fb_*() handling and still
use drm_fb_helper_deferred_io().


For those who likes details, this is fbcon unblanking which results in a
full display update on a 320x240 display, shell with blinking cursor on
the last line of the console:

[ 5505.164150] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
[ 5505.164186] [drm:drm_atomic_state_init] Allocated atomic state b859e400
[...more drm atomic msgs...]
[ 5505.164713] drm_fb_helper_dirty: x=152,width=8,y=224,height=16
[ 5505.164746] [drm:drm_atomic_state_init] Allocated atomic state b859e440
[...more drm atomic msgs...]
[ 5505.165086] drm_fb_helper_dirty: x=0,width=320,y=0,height=16
[ 5505.165153] drm_fb_helper_dirty: x=0,width=320,y=16,height=16
[ 5505.165220] drm_fb_helper_dirty: x=0,width=320,y=32,height=16
[ 5505.165287] drm_fb_helper_dirty: x=0,width=320,y=48,height=16
[ 5505.165354] drm_fb_helper_dirty: x=0,width=320,y=64,height=16
[ 5505.165420] drm_fb_helper_dirty: x=0,width=320,y=80,height=16
[ 5505.165487] drm_fb_helper_dirty: x=0,width=320,

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #6 from Felix Schwarz  ---
"bisecting" is a way to find out which commit caused a specific regression.
This involves compiling the linux kernel from git and testing the compiled
versions. If you can find out which commit is the culprit chances are pretty
good that the problem can be fixed quickly.

To learn more about bisecting I suggest seaching for "git bisect".

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/b4038ce9/attachment.html>

[GIT PULL v3] drm-hisilicon-next for 4.7

2016-04-29 Thread Xinliang Liu

Hi Dave,

v3:
This driver should only work on arm64 system.
So add ARM64 depends on to the Kconfig in this commit:
23e7b2ab9a8f drm/hisilicon: Add hisilicon kirin drm master driver

The 32-bit system compilation warnings and errors should not be existed.
Please help to try and let me know if there is any problem.

Thanks,
-xinliang

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu
into drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:

for you to fetch changes up to c84ffde963e227bf68efb12315bd39c75e00ff05:

  MAINTAINERS: Add maintainer for hisilicon DRM driver (2016-04-29
16:39:15 +0800)


drm-hisilicon-next for 4.7

Add new hisilicon kirin drm driver:
- Add maintainer for hisilicon DRM driver
- Add support for external bridge
- Add designware dsi host driver
- Add designware dsi encoder driver
- Add cma fbdev and hotplug
- Add vblank driver for ADE
- Add plane driver for ADE
- Add crtc driver for ADE
- Add hisilicon kirin drm master driver
- Add device tree binding for hi6220 display subsystem


Xinliang Liu (10):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver

 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt   |   72 ++
 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt |   64 ++
 MAINTAINERS  |   10 +
 drivers/gpu/drm/Kconfig  |2 +
 drivers/gpu/drm/Makefile |1 +
 drivers/gpu/drm/hisilicon/Kconfig|5 +
 drivers/gpu/drm/hisilicon/Makefile   |5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig  |   18 ++
 drivers/gpu/drm/hisilicon/kirin/Makefile |6 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |
857 +
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |
103 +
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h  |
230 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  |
1057 
++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c  |
367 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  |   31 +++
 15 files changed, 2828 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

[Bug 95198] Shadow of Mordor beta has missing geometry with gl 4.3

https://bugs.freedesktop.org/show_bug.cgi?id=95198

--- Comment #3 from Nicolai Hï¿½hnle  ---
I'm not sure why that is, but I'd say it's good news. Perhaps you can provide
an apitrace of the remaining problems?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/9c747932/attachment.html>

[PATCH 2/2 v2] ARC: [axs10x] Specify reserved memory for frame buffer

2016-04-29 Thread Vineet Gupta

On Thursday 28 April 2016 07:49 PM, Alexey Brodkin wrote:
> Even though for AXS101 (which sorts ARC770 CPU) IOC is not
> an option for a sake of keeping one DT description for the
> base-board (axs10x_mb.dtsi) we're still defining reserved
> memory location in the very end of DDR.
> 
> Signed-off-by: Alexey Brodkin 

Acked-by: Vineet Gupta

[Bug 94043] Distorted graphics when running Battle.net app under Wine with Radeon hardware

https://bugs.freedesktop.org/show_bug.cgi?id=94043

Erik Brangs  changed:

   What|Removed |Added

Version|11.0|11.2

--- Comment #14 from Erik Brangs  ---
Still happening in Ubuntu 16.04 LTS which ships Mesa 11.2.0.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/6cd3cb09/attachment.html>

[PATCHv16 13/13] vivid: add CEC emulation

From: Hans Verkuil 

The vivid driver has been extended to provide CEC adapters for the HDMI
input and HDMI outputs in order to test CEC applications.

This CEC emulation is faithful to the CEC timings (i.e., it all at a
snail's pace).

Signed-off-by: Hans Verkuil 
---
 Documentation/video4linux/vivid.txt  |  36 +++-
 drivers/media/platform/vivid/Kconfig |   9 +
 drivers/media/platform/vivid/Makefile|   4 +
 drivers/media/platform/vivid/vivid-cec.c | 254 +++
 drivers/media/platform/vivid/vivid-cec.h |  33 +++
 drivers/media/platform/vivid/vivid-core.c| 119 ++-
 drivers/media/platform/vivid/vivid-core.h|  27 +++
 drivers/media/platform/vivid/vivid-kthread-cap.c |  11 +
 drivers/media/platform/vivid/vivid-vid-cap.c |  23 +-
 drivers/media/platform/vivid/vivid-vid-common.c  |   7 +
 10 files changed, 508 insertions(+), 15 deletions(-)
 create mode 100644 drivers/media/platform/vivid/vivid-cec.c
 create mode 100644 drivers/media/platform/vivid/vivid-cec.h

diff --git a/Documentation/video4linux/vivid.txt 
b/Documentation/video4linux/vivid.txt
index 8da5d2a..1b26519 100644
--- a/Documentation/video4linux/vivid.txt
+++ b/Documentation/video4linux/vivid.txt
@@ -74,7 +74,8 @@ Section 11: Cropping, Composing, Scaling
 Section 12: Formats
 Section 13: Capture Overlay
 Section 14: Output Overlay
-Section 15: Some Future Improvements
+Section 15: CEC (Consumer Electronics Control)
+Section 16: Some Future Improvements


 Section 1: Configuring the driver
@@ -364,7 +365,11 @@ For HDMI inputs it is possible to set the EDID. By default 
a simple EDID
 is provided. You can only set the EDID for HDMI inputs. Internally, however,
 the EDID is shared between all HDMI inputs.

-No interpretation is done of the EDID data.
+No interpretation is done of the EDID data with the exception of the
+physical address. See the CEC section for more details.
+
+There is a maximum of 15 HDMI inputs (if there are more, then they will be
+reduced to 15) since that's the limitation of the EDID physical address.


 Section 3: Video Output
@@ -409,6 +414,9 @@ standard, and for all others a 1:1 pixel aspect ratio is 
returned.

 An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID.

+There is a maximum of 15 HDMI outputs (if there are more, then they will be
+reduced to 15) since that's the limitation of the EDID physical address. See
+also the CEC section for more details.

 Section 4: VBI Capture
 --
@@ -1108,7 +1116,26 @@ capabilities will slow down the video loop considerably 
as a lot of checks have
 to be done per pixel.


-Section 15: Some Future Improvements
+Section 15: CEC (Consumer Electronics Control)
+--
+
+If there are HDMI inputs then a CEC adapter will be created that has
+the same number of input ports. This is the equivalent of e.g. a TV that
+has that number of inputs. Each HDMI output will also create a
+CEC adapter that is hooked up to the corresponding input port, or (if there
+are more outputs than inputs) is not hooked up at all. In other words,
+this is the equivalent of hooking up each output device to an input port of
+the TV. Any remaining output devices remain unconnected.
+
+The EDID that each output reads reports a unique CEC physical address that is
+based on the physical address of the EDID of the input. So if the EDID of the
+receiver has physical address A.B.0.0, then each output will see an EDID
+containing physical address A.B.C.0 where C is 1 to the number of inputs. If
+there are more outputs than inputs then the remaining outputs have a CEC 
adapter
+that is disabled and reports an invalid physical address.
+
+
+Section 16: Some Future Improvements
 

 Just as a reminder and in no particular order:
@@ -1121,8 +1148,6 @@ Just as a reminder and in no particular order:
 - Fix sequence/field numbering when looping of video with alternate fields
 - Add support for V4L2_CID_BG_COLOR for video outputs
 - Add ARGB888 overlay support: better testing of the alpha channel
-- Add custom DV timings support
-- Add support for V4L2_DV_FL_REDUCED_FPS
 - Improve pixel aspect support in the tpg code by passing a real v4l2_fract
 - Use per-queue locks and/or per-device locks to improve throughput
 - Add support to loop from a specific output to a specific input across
@@ -1133,3 +1158,4 @@ Just as a reminder and in no particular order:
 - Make a thread for the RDS generation, that would help in particular for the
   "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated
   in real-time.
+- Changing the EDID should cause hotplug detect emulation to happen.
diff --git a/drivers/media/platform/vivid/Kconfig 
b/drivers/media/platform/vivid/Kconfig
index f535f57..20c5eea 100644
--- a/drivers/media/platform/vivid/Kconfig
+++ b/drivers/media/platform/vivid/Kconfig
@@ -6,6 +6,7 @@ config VIDEO_V

[PATCHv16 12/13] cec: s5p-cec: Add s5p-cec driver

From: Kamil Debski 

Add CEC interface driver present in the Samsung Exynos range of
SoCs.

The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/s5p-cec.txt  |  31 +++
 MAINTAINERS|   7 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/s5p-cec/Makefile|   2 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |  38 +++
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   | 209 +++
 drivers/media/platform/s5p-cec/regs-cec.h  |  96 +++
 drivers/media/platform/s5p-cec/s5p_cec.c   | 295 +
 drivers/media/platform/s5p-cec/s5p_cec.h   |  76 ++
 10 files changed, 766 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..925ab4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,31 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be following
+   "samsung,s5p-cec"
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "hdmicec",
+ corresponding to entry in the clocks property.
+  - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+hdmicec: cec at 100B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x100B 0x200>;
+   interrupts = <0 114 0>;
+   clocks = <&clock CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <&pmu_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_cec>;
+   status = "okay";
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 83bd865..0e43b30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1581,6 +1581,13 @@ L:   linux-media at vger.kernel.org
 S: Maintained
 F: drivers/media/platform/s5p-tv/

+ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
+M: Kyungmin Park 
+L: linux-arm-kernel at lists.infradead.org
+L: linux-media at vger.kernel.org
+S: Maintained
+F: drivers/media/platform/s5p-cec/
+
 ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
 M: Andrzej Pietrasiewicz 
 M: Jacek Anaszewski 
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 84e041c..c3945c3 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -108,6 +108,17 @@ config VIDEO_S3C_CAMIF
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/s5p-tv/Kconfig"
+
+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC && (PLAT_S5P || ARCH_EXYNOS || 
COMPILE_TEST)
+   default n
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..f598c80 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += 
m2m-deinterlace.o

 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..0e2cf45
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,2 @@
+obj-$(C

[PATCHv16 11/13] cec: adv7511: add cec support.

From: Hans Verkuil 

Add CEC support to the adv7511 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/Kconfig   |   9 +
 drivers/media/i2c/adv7511.c | 401 +++-
 include/media/i2c/adv7511.h |   6 +-
 3 files changed, 403 insertions(+), 13 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 5168454..6c2acb6 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -465,6 +465,7 @@ config VIDEO_ADV7511
tristate "Analog Devices ADV7511 encoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
select HDMI
+   select MEDIA_CEC_EDID
---help---
  Support for the Analog Devices ADV7511 video encoder.

@@ -473,6 +474,14 @@ config VIDEO_ADV7511
  To compile this driver as a module, choose M here: the
  module will be called adv7511.

+config VIDEO_ADV7511_CEC
+   bool "Enable Analog Devices ADV7511 CEC support"
+   depends on VIDEO_ADV7511 && MEDIA_CEC
+   default y
+   ---help---
+ When selected the adv7511 will support the optional
+ HDMI CEC feature.
+
 config VIDEO_AD9389B
tristate "Analog Devices AD9389B encoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 39271c3..002117b 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 static int debug;
 module_param(debug, int, 0644);
@@ -59,6 +60,8 @@ MODULE_LICENSE("GPL v2");
 #define ADV7511_MIN_PIXELCLOCK 2000
 #define ADV7511_MAX_PIXELCLOCK 22500

+#define ADV7511_MAX_ADDRS (3)
+
 /*
 **
 *
@@ -90,12 +93,20 @@ struct adv7511_state {
struct v4l2_ctrl_handler hdl;
int chip_revision;
u8 i2c_edid_addr;
-   u8 i2c_cec_addr;
u8 i2c_pktmem_addr;
+   u8 i2c_cec_addr;
+
+   struct i2c_client *i2c_cec;
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
bool have_monitor;
+   bool enabled_irq;
/* timings from s_dv_timings */
struct v4l2_dv_timings dv_timings;
u32 fmt_code;
@@ -227,7 +238,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client 
*client,
return ret;
 }

-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
 {
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -242,6 +253,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, 
u16 len, u8 *buf)
v4l2_err(sd, "%s: i2c read error\n", __func__);
 }

+static inline int adv7511_cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+
+   return i2c_smbus_read_byte_data(state->i2c_cec, reg);
+}
+
+static int adv7511_cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+   int ret;
+   int i;
+
+   for (i = 0; i < 3; i++) {
+   ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val);
+   if (ret == 0)
+   return 0;
+   }
+   v4l2_err(sd, "%s: I2C Write Problem\n", __func__);
+   return ret;
+}
+
+static inline int adv7511_cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 
mask,
+  u8 val)
+{
+   return adv7511_cec_write(sd, reg, (adv7511_cec_read(sd, reg) & mask) | 
val);
+}
+
 static int adv7511_pktmem_rd(struct v4l2_subdev *sd, u8 reg)
 {
struct adv7511_state *state = get_adv7511_state(sd);
@@ -425,16 +464,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
 #ifdef CONFIG_VIDEO_ADV_DEBUG
 static void adv7511_inv_register(struct v4l2_subdev *sd)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, "0x000-0x0ff: Main Map\n");
+   if (state->i2c_cec)
+   v4l2_info(sd, "0x100-0x1ff: CEC Map\n");
 }

 static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register 
*reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
reg->size = 1;
switch (reg->reg >> 8) {
case 0:
reg->val = adv7511_rd(sd, reg->reg & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   reg->val = adv7511_cec_read(sd, reg->reg & 0xff);
+   break;
+   }
+

[PATCHv16 10/13] cec: adv7842: add cec support

From: Hans Verkuil 

Add CEC support to the adv7842 driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/Kconfig   |   9 ++
 drivers/media/i2c/adv7842.c | 368 
 2 files changed, 314 insertions(+), 63 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cba1fc7..5168454 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -231,6 +231,7 @@ config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
select HDMI
+   select MEDIA_CEC_EDID
---help---
  Support for the Analog Devices ADV7842 video decoder.

@@ -240,6 +241,14 @@ config VIDEO_ADV7842
  To compile this driver as a module, choose M here: the
  module will be called adv7842.

+config VIDEO_ADV7842_CEC
+   bool "Enable Analog Devices ADV7842 CEC support"
+   depends on VIDEO_ADV7842 && MEDIA_CEC
+   default y
+   ---help---
+ When selected the adv7842 will support the optional
+ HDMI CEC feature.
+
 config VIDEO_BT819
tristate "BT819A VideoStream decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index ecaacb0..297ba7a 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,6 +80,8 @@ MODULE_LICENSE("GPL");

 #define ADV7842_OP_SWAP_CB_CR  (1 << 0)

+#define ADV7842_MAX_ADDRS (3)
+
 /*
 **
 *
@@ -142,6 +145,11 @@ struct adv7842_state {
struct v4l2_ctrl *free_run_color_ctrl_manual;
struct v4l2_ctrl *free_run_color_ctrl;
struct v4l2_ctrl *rgb_quantization_range_ctrl;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV7842_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
 };

 /* Unsupported timings. This device cannot support 720p30. */
@@ -418,9 +426,9 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, 
u8 val)
return adv_smbus_write_byte_data(state->i2c_cec, reg, val);
 }

-static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, 
u8 val)
 {
-   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+   return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
 }

 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
@@ -696,6 +704,18 @@ adv7842_get_dv_timings_cap(struct v4l2_subdev *sd)

 /* --- */

+static u16 adv7842_read_cable_det(struct v4l2_subdev *sd)
+{
+   u8 reg = io_read(sd, 0x6f);
+   u16 val = 0;
+
+   if (reg & 0x02)
+   val |= 1; /* port A */
+   if (reg & 0x01)
+   val |= 2; /* port B */
+   return val;
+}
+
 static void adv7842_delayed_work_enable_hotplug(struct work_struct *work)
 {
struct delayed_work *dwork = to_delayed_work(work);
@@ -762,50 +782,18 @@ static int edid_write_vga_segment(struct v4l2_subdev *sd)
return 0;
 }

-static int edid_spa_location(const u8 *edid)
-{
-   u8 d;
-
-   /*
-* TODO, improve and update for other CEA extensions
-* currently only for 1 segment (256 bytes),
-* i.e. 1 extension block and CEA revision 3.
-*/
-   if ((edid[0x7e] != 1) ||
-   (edid[0x80] != 0x02) ||
-   (edid[0x81] != 0x03)) {
-   return -EINVAL;
-   }
-   /*
-* search Vendor Specific Data Block (tag 3)
-*/
-   d = edid[0x82] & 0x7f;
-   if (d > 4) {
-   int i = 0x84;
-   int end = 0x80 + d;
-   do {
-   u8 tag = edid[i]>>5;
-   u8 len = edid[i] & 0x1f;
-
-   if ((tag == 3) && (len >= 5))
-   return i + 4;
-   i += len + 1;
-   } while (i < end);
-   }
-   return -EINVAL;
-}
-
 static int edid_write_hdmi_segment(struct v4l2_subdev *sd, u8 port)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct adv7842_state *state = to_state(sd);
-   const u8 *val = state->hdmi_edid.edid;
-   int spa_loc = edid_spa_location(val);
+   const u8 *edid = state->hdmi_edid.edid;
+   int spa_loc;
+   u16 pa;
int err = 0;
int i;

-   v4l2_dbg(2, debug, sd, "%s: write EDID on port %c (spa at 0x%x)\n",
-   __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B', 
spa_loc);
+   v4l2_dbg(2, debug, sd, "%s: write EDID on port %c\n",
+   __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B');

/* HPA disable on port A and B

[PATCHv16 09/13] cec: adv7604: add cec support.

From: Hans Verkuil 

Add CEC support to the adv7604 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
[k.debski at samsung.com: add missing methods cec/io_write_and_or]
[k.debski at samsung.com: change adv7604 to adv76xx in added functions]
[hansverk at cisco.com: use _clr_set instead of _and_or]
---
 drivers/media/i2c/Kconfig   |   9 ++
 drivers/media/i2c/adv7604.c | 332 +++-
 2 files changed, 305 insertions(+), 36 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 993dc50..cba1fc7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -209,6 +209,7 @@ config VIDEO_ADV7604
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on GPIOLIB || COMPILE_TEST
select HDMI
+   select MEDIA_CEC_EDID
---help---
  Support for the Analog Devices ADV7604 video decoder.

@@ -218,6 +219,14 @@ config VIDEO_ADV7604
  To compile this driver as a module, choose M here: the
  module will be called adv7604.

+config VIDEO_ADV7604_CEC
+   bool "Enable Analog Devices ADV7604 CEC support"
+   depends on VIDEO_ADV7604 && MEDIA_CEC
+   default y
+   ---help---
+ When selected the adv7604 will support the optional
+ HDMI CEC feature.
+
 config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index beb2841..f462585 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -40,6 +40,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,6 +81,8 @@ MODULE_LICENSE("GPL");

 #define ADV76XX_OP_SWAP_CB_CR  (1 << 0)

+#define ADV76XX_MAX_ADDRS (3)
+
 enum adv76xx_type {
ADV7604,
ADV7611,
@@ -184,6 +187,12 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+
+   struct cec_adapter *cec_adap;
+   u8   cec_addr[ADV76XX_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -381,7 +390,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, 
u8 val)
return regmap_write(state->regmap[ADV76XX_PAGE_IO], reg, val);
 }

-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
 {
return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val);
 }
@@ -414,6 +424,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 
reg, u8 val)
return regmap_write(state->regmap[ADV76XX_PAGE_CEC], reg, val);
 }

+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
+}
+
 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
 {
struct adv76xx_state *state = to_state(sd);
@@ -872,9 +888,9 @@ static int adv76xx_s_detect_tx_5v_ctrl(struct v4l2_subdev 
*sd)
 {
struct adv76xx_state *state = to_state(sd);
const struct adv76xx_chip_info *info = state->info;
+   u16 cable_det = info->read_cable_det(sd);

-   return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl,
-   info->read_cable_det(sd));
+   return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
 }

 static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
@@ -1900,6 +1916,210 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
 }

+#if IS_ENABLED(CONFIG_VIDEO_ADV7604_CEC)
+static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+   struct adv76xx_state *state = to_state(sd);
+
+   if ((cec_read(sd, 0x11) & 0x01) == 0) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+   return;
+   }
+
+   if (tx_raw_status & 0x02) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n",
+__func__);
+   cec_transmit_done(state->cec_adap, CEC_TX_STATUS_ARB_LOST,
+ 1, 0, 0, 0);
+   }
+   if (tx_raw_status & 0x04) {
+   u8 status;
+   u8 nack_cnt;
+   u8 low_drive_cnt;
+
+   v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+   /*
+* We set this status bit since this hardware performs
+* retransmissions.
+*/
+   status = CEC_TX_STATUS_MAX_RETRIES;
+   nack_cnt

[PATCHv16 08/13] DocBook/media: add CEC documentation

From: Hans Verkuil 

Add DocBook documentation for the CEC API.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: add documentation for passthrough mode]
[k.debski at samsung.com: minor fixes and change of reserved field sizes]
Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/device-drivers.tmpl  |   4 +
 Documentation/DocBook/media/Makefile   |   2 +
 Documentation/DocBook/media/v4l/biblio.xml |  10 +
 Documentation/DocBook/media/v4l/cec-api.xml|  72 +
 Documentation/DocBook/media/v4l/cec-func-close.xml |  59 
 Documentation/DocBook/media/v4l/cec-func-ioctl.xml |  73 +
 Documentation/DocBook/media/v4l/cec-func-open.xml  |  94 ++
 Documentation/DocBook/media/v4l/cec-func-poll.xml  |  89 ++
 .../DocBook/media/v4l/cec-ioc-adap-g-caps.xml  | 140 +
 .../DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 324 +
 .../DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml |  82 ++
 .../DocBook/media/v4l/cec-ioc-dqevent.xml  | 190 
 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 245 
 .../DocBook/media/v4l/cec-ioc-receive.xml  | 260 +
 Documentation/DocBook/media_api.tmpl   |   6 +-
 15 files changed, 1649 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 893b2ca..31258bf 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -270,6 +270,10 @@ X!Isound/sound_firmware.c
 !Iinclude/media/media-devnode.h
 !Iinclude/media/media-entity.h
 
+ Consumer Electronics Control devices
+!Iinclude/media/cec.h
+!Iinclude/media/cec-edid.h
+ 

   

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index 2840ff4..fdc1386 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -64,6 +64,7 @@ IOCTLS = \
$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \

 DEFINES = \
@@ -100,6 +101,7 @@ STRUCTS = \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-mediabus.h)

diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index 9beb30f..87f1d24 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -342,6 +342,16 @@ in the frequency range from 87,5 to 108,0 MHz
   Specification Version 1.4a
 

+
+  HDMI2
+  
+   HDMI Licensing LLC
+(http://www.hdmi.org";>http://www.hdmi.org)
+  
+  High-Definition Multimedia Interface
+  Specification Version 2.0
+
+
 
   DP
   
diff --git a/Documentation/DocBook/media/v4l/cec-api.xml 
b/Documentation/DocBook/media/v4l/cec-api.xml
new file mode 100644
index 000..caa04c0
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/cec-api.xml
@@ -0,0 +1,72 @@
+
+  
+
+  Hans
+  Verkuil
+  hans.verkuil at 
cisco.com
+  In

[PATCHv16 07/13] cec.txt: add CEC framework documentation

From: Hans Verkuil 

Document the new HDMI CEC framework.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with
Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 Documentation/cec.txt | 267 ++
 1 file changed, 267 insertions(+)
 create mode 100644 Documentation/cec.txt

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..75155fe
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,267 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple types of hardware (receivers,
+transmitters, USB dongles). The framework also gives the option to decide
+what to do in the kernel driver and what should be handled by userspace
+applications. In addition it integrates the remote control passthrough
+feature into the kernel's remote control framework.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables consumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physical address is determined by the physical
+connection between devices.
+
+The CEC framework described here is up to date with the CEC 2.0 specification.
+It is documented in the HDMI 1.4 specification with the new 2.0 bits documented
+in the HDMI 2.0 specification. But for most of the features the freely 
available
+HDMI 1.3a specification is sufficient:
+
+http://www.microprocessor.org/HDMISpecification13a.pdf
+
+
+The Kernel Interface
+
+
+CEC Adapter
+---
+
+The struct cec_adapter represents the CEC adapter hardware. It is created by
+calling cec_allocate_adapter() and deleted by calling cec_delete_adapter():
+
+struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
+  void *priv, const char *name, u32 caps, u8 available_las,
+  struct device *parent);
+void cec_delete_adapter(struct cec_adapter *adap);
+
+To create an adapter you need to pass the following information:
+
+ops: adapter operations which are called by the CEC framework and that you
+have to implement.
+
+priv: will be stored in adap->priv and can be used by the adapter ops.
+
+name: the name of the CEC adapter. Note: this name will be copied.
+
+caps: capabilities of the CEC adapter. These capabilities determine the
+   capabilities of the hardware and which parts are to be handled
+   by userspace and which parts are handled by kernelspace. The
+   capabilities are returned by CEC_ADAP_G_CAPS.
+
+available_las: the number of simultaneous logical addresses that this
+   adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS.
+
+parent: the parent device.
+
+
+To register the /dev/cecX device node and the remote control device (if
+CEC_CAP_RC is set) you call:
+
+int cec_register_adapter(struct cec_adapter *adap);
+
+To unregister the devices call:
+
+void cec_unregister_adapter(struct cec_adapter *adap);
+
+Note: if cec_register_adapter() fails, then call cec_delete_adapter() to
+clean up. But if cec_register_adapter() succeeded, then only call
+cec_unregister_adapter() to clean up, never cec_delete_adapter(). The
+unregister function will delete the adapter automatically once the last user
+of that /dev/cecX device has closed its file handle.
+
+
+Implementing the Low-Level CEC Adapter
+--
+
+The following low-level adapter operations have to be implemented in
+your driver:
+
+struct cec_adap_ops {
+   /* Low-level callbacks */
+   int (*adap_enable)(struct cec_adapter *adap, bool enable);
+   int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
+   int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+   int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
+u32 signal_free_time, struct cec_msg *msg);
+   void (*adap_log_status)(struct cec_adapter *adap);
+
+   /* High-level callbacks */
+   ...
+};
+
+The three low-level ops deal with various aspects of controlling the CEC 
adapter
+hardware:
+
+
+To enable/disable the hardware:
+
+   int (*adap_enable)(struct cec_adapter *adap, bool enable);
+
+This callback enables or disables the CEC hardware. Enabling the CEC hardware
+means powering it up in a state where no logical addresses are claimed. This
+op assumes that the physical address (adap->phys_addr) is valid when enable is
+true and will not change while the CEC adapter remains enabled. The initial
+state of the CEC adapter after calling cec_allocate_adapter() is disabled.
+
+Note that adap_enable must return 0 if enable is false

[PATCHv16 06/13] cec: add compat32 ioctl support

From: Hans Verkuil 

The CEC ioctls didn't have compat32 support, so they returned -ENOTTY
when used in a 32 bit application on a 64 bit kernel.

Since all the CEC ioctls are 32-bit compatible adding support for this
API is trivial.

Signed-off-by: Hans Verkuil 
---
 fs/compat_ioctl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index bd01b92..c1e9f29 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "internal.h"

@@ -1377,6 +1378,17 @@ COMPATIBLE_IOCTL(VIDEO_GET_NAVI)
 COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES)
 COMPATIBLE_IOCTL(VIDEO_GET_SIZE)
 COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE)
+/* cec */
+COMPATIBLE_IOCTL(CEC_ADAP_G_CAPS)
+COMPATIBLE_IOCTL(CEC_ADAP_G_LOG_ADDRS)
+COMPATIBLE_IOCTL(CEC_ADAP_S_LOG_ADDRS)
+COMPATIBLE_IOCTL(CEC_ADAP_G_PHYS_ADDR)
+COMPATIBLE_IOCTL(CEC_ADAP_S_PHYS_ADDR)
+COMPATIBLE_IOCTL(CEC_G_MODE)
+COMPATIBLE_IOCTL(CEC_S_MODE)
+COMPATIBLE_IOCTL(CEC_TRANSMIT)
+COMPATIBLE_IOCTL(CEC_RECEIVE)
+COMPATIBLE_IOCTL(CEC_DQEVENT)

 /* joystick */
 COMPATIBLE_IOCTL(JSIOCGVERSION)
-- 
2.8.1

[PATCHv16 05/13] cec/TODO: add TODO file so we know why this is still in staging

From: Hans Verkuil 

Explain why cec.c is still in staging.

Signed-off-by: Hans Verkuil 
---
 drivers/staging/media/cec/TODO | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 drivers/staging/media/cec/TODO

diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO
new file mode 100644
index 000..c0751ef
--- /dev/null
+++ b/drivers/staging/media/cec/TODO
@@ -0,0 +1,13 @@
+The reason why cec.c is still in staging is that I would like
+to have a bit more confidence in the uABI. The kABI is fine,
+no problem there, but I would like to let the public API mature
+a bit.
+
+Once I'm confident that I didn't miss anything then the cec.c source
+can move to drivers/media and the linux/cec.h and linux/cec-funcs.h
+headers can move to uapi/linux and added to uapi/linux/Kbuild to make
+them public.
+
+Hopefully this will happen later in 2016.
+
+Hans Verkuil 
-- 
2.8.1

[PATCHv16 04/13] cec: add HDMI CEC framework

From: Hans Verkuil 

The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.

Besides the cec module itself it also adds a cec-edid module that
contains helper functions to find and manipulate the CEC physical
address inside an EDID. Even if the CEC support itself is disabled,
drivers will still need these functions.

Note that the CEC framework is added to staging/media and that the
cec.h and cec-funcs.h headers are not exported yet. While the kABI
is mature, I would prefer to allow the uABI some more time before
it is mainlined in case it needs more tweaks.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski at samsung.com: change kthread handling when setting logical
address]
[k.debski at samsung.com: code cleanup and fixes]
[k.debski at samsung.com: add missing CEC commands to match spec]
[k.debski at samsung.com: add RC framework support]
[k.debski at samsung.com: move and edit documentation]
[k.debski at samsung.com: add vendor id reporting]
[k.debski at samsung.com: add possibility to clear assigned logical
addresses]
[k.debski at samsung.com: documentation fixes, clenaup and expansion]
[k.debski at samsung.com: reorder of API structs and add reserved fields]
[k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
problem]
[k.debski at samsung.com: add sequence number handling]
[k.debski at samsung.com: add passthrough mode]
[k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands]
minor additions]
Signed-off-by: Kamil Debski 
---
 MAINTAINERS|   16 +
 drivers/media/Kconfig  |3 +
 drivers/media/Makefile |2 +
 drivers/media/cec-edid.c   |  139 ++
 drivers/staging/media/Kconfig  |2 +
 drivers/staging/media/Makefile |1 +
 drivers/staging/media/cec/Kconfig  |8 +
 drivers/staging/media/cec/Makefile |1 +
 drivers/staging/media/cec/cec.c| 2481 
 include/linux/cec-funcs.h  | 1871 +++
 include/linux/cec.h|  985 ++
 include/media/cec-edid.h   |  103 ++
 include/media/cec.h|  236 
 13 files changed, 5848 insertions(+)
 create mode 100644 drivers/media/cec-edid.c
 create mode 100644 drivers/staging/media/cec/Kconfig
 create mode 100644 drivers/staging/media/cec/Makefile
 create mode 100644 drivers/staging/media/cec/cec.c
 create mode 100644 include/linux/cec-funcs.h
 create mode 100644 include/linux/cec.h
 create mode 100644 include/media/cec-edid.h
 create mode 100644 include/media/cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index bfcb7ea..83bd865 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2760,6 +2760,22 @@ F:   drivers/net/ieee802154/cc2520.c
 F: include/linux/spi/cc2520.h
 F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt

+CEC DRIVER
+M: Hans Verkuil 
+L: linux-media at vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: Documentation/cec.txt
+F: Documentation/DocBook/media/v4l/cec*
+F: drivers/staging/media/cec/cec.c
+F: drivers/media/cec-edid.c
+F: drivers/media/rc/keymaps/rc-cec.c
+F: include/media/cec.h
+F: include/media/cec-edid.h
+F: include/linux/cec.h
+F: include/linux/cec-funcs.h
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-dev at lists.ozlabs.org
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index a8518fb..052dcf7 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -80,6 +80,9 @@ config MEDIA_RC_SUPPORT

  Say Y when you have a TV or an IR device.

+config MEDIA_CEC_EDID
+   tristate
+
 #
 # Media controller
 #  Selectable only for webcam/grabbers, as other drivers don't use it
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index e608bbc..b56f013 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the kernel multimedia device drivers.
 #

+obj-$(CONFIG_MEDIA_CEC_EDID) += cec-edid.o
+
 media-objs := media-device.o media-devnode.o media-entity.o

 #
diff --git a/drivers/media/cec-edid.c b/drivers/media/cec-edid.c
new file mode 100644
index 000..50202d8
--- /dev/null
+++ b/drivers/media/cec-edid.c
@@ -0,0 +1,139 @@
+/*
+ * cec-edid - HDMI Consumer Electronics Control EDID & CEC helper functions
+ *
+ * Copyright 2016 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

[PATCHv16 03/13] rc: Add HDMI CEC protocol handling

From: Kamil Debski 

Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 drivers/media/rc/keymaps/Makefile |   1 +
 drivers/media/rc/keymaps/rc-cec.c | 174 ++
 drivers/media/rc/rc-main.c|   1 +
 include/media/rc-map.h|   5 +-
 4 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index fbbd3bb..9cffcc6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+   rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c 
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..193cdca
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,174 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+/* CEC Spec "High-Definition Multimedia Interface Specification" can be 
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+   { 0x00, KEY_OK },
+   { 0x01, KEY_UP },
+   { 0x02, KEY_DOWN },
+   { 0x03, KEY_LEFT },
+   { 0x04, KEY_RIGHT },
+   { 0x05, KEY_RIGHT_UP },
+   { 0x06, KEY_RIGHT_DOWN },
+   { 0x07, KEY_LEFT_UP },
+   { 0x08, KEY_LEFT_DOWN },
+   { 0x09, KEY_ROOT_MENU }, /* CEC Spec: Device Root Menu - see Note 2 */
+   /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device's current state. */
+   { 0x0a, KEY_SETUP },
+   { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+   { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+   { 0x0d, KEY_EXIT },
+   /* 0x0e-0x0f: Reserved */
+   { 0x10, KEY_MEDIA_TOP_MENU },
+   { 0x11, KEY_CONTEXT_MENU },
+   /* 0x12-0x1c: Reserved */
+   { 0x1d, KEY_DIGITS }, /* CEC Spec: select/toggle a Number Entry Mode */
+   { 0x1e, KEY_NUMERIC_11 },
+   { 0x1f, KEY_NUMERIC_12 },
+   /* 0x20-0x29: Keys 0 to 9 */
+   { 0x20, KEY_NUMERIC_0 },
+   { 0x21, KEY_NUMERIC_1 },
+   { 0x22, KEY_NUMERIC_2 },
+   { 0x23, KEY_NUMERIC_3 },
+   { 0x24, KEY_NUMERIC_4 },
+   { 0x25, KEY_NUMERIC_5 },
+   { 0x26, KEY_NUMERIC_6 },
+   { 0x27, KEY_NUMERIC_7 },
+   { 0x28, KEY_NUMERIC_8 },
+   { 0x29, KEY_NUMERIC_9 },
+   { 0x2a, KEY_DOT },
+   { 0x2b, KEY_ENTER },
+   { 0x2c, KEY_CLEAR },
+   /* 0x2d-0x2e: Reserved */
+   { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */
+   { 0x30, KEY_CHANNELUP },
+   { 0x31, KEY_CHANNELDOWN },
+   { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+   { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+   { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */
+   { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+   { 0x36, KEY_HELP },
+   { 0x37, KEY_PAGEUP },
+   { 0x38, KEY_PAGEDOWN },
+   /* 0x39-0x3f: Reserved */
+   { 0x40, KEY_POWER },
+   { 0x41, KEY_VOLUMEUP },
+   { 0x42, KEY_VOLUMEDOWN },
+   { 0x43, KEY_MUTE },
+   { 0x44, KEY_PLAYCD },
+   { 0x45, KEY_STOPCD },
+   { 0x46, KEY_PAUSECD },
+   { 0x47, KEY_RECORD },
+   { 0x48, KEY_REWIND },
+   { 0x49, KEY_FASTFORWARD },
+   { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+   { 0x4b, KEY_FORWARD },
+   { 0x4c, KEY_BACK },
+   { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */
+   { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */
+   /* 0x4f: Reserved */
+   { 0x50, KEY_ANGLE },
+   { 0x51, KEY_TV2 },
+   { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */
+   { 0x53, KEY_EPG },
+   { 0x54, KEY_TIME }, /* CEC Spec: Timer */
+   { 0x55, KEY_CONFIG },
+   /* The following codes are hard to implement at this moment, as they
+

[PATCHv16 02/13] HID: add HDMI CEC specific keycodes

From: Kamil Debski 

Add HDMI CEC specific keycodes to the keycodes definition.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
Acked-by: Dmitry Torokhov 
---
 include/uapi/linux/input-event-codes.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/uapi/linux/input-event-codes.h 
b/include/uapi/linux/input-event-codes.h
index 87cf351..02b7b3a 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -611,6 +611,36 @@
 #define KEY_KBDINPUTASSIST_ACCEPT  0x264
 #define KEY_KBDINPUTASSIST_CANCEL  0x265

+/* Diagonal movement keys */
+#define KEY_RIGHT_UP   0x266
+#define KEY_RIGHT_DOWN 0x267
+#define KEY_LEFT_UP0x268
+#define KEY_LEFT_DOWN  0x269
+
+#define KEY_ROOT_MENU  0x26a /* Show Device's Root Menu */
+#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media 
(e.g. DVD) */
+#define KEY_NUMERIC_11 0x26c
+#define KEY_NUMERIC_12 0x26d
+/*
+ * Toggle Audio Description: refers to an audio service that helps blind and
+ * visually impaired consumers understand the action in a program. Note: in
+ * some countries this is referred to as "Video Description".
+ */
+#define KEY_AUDIO_DESC 0x26e
+#define KEY_3D_MODE0x26f
+#define KEY_NEXT_FAVORITE  0x270
+#define KEY_STOP_RECORD0x271
+#define KEY_PAUSE_RECORD   0x272
+#define KEY_VOD0x273 /* Video on Demand */
+#define KEY_UNMUTE 0x274
+#define KEY_FASTREVERSE0x275
+#define KEY_SLOWREVERSE0x276
+/*
+ * Control a data application associated with the currently viewed channel,
+ * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.)
+ */
+#define KEY_DATA   0x275
+
 #define BTN_TRIGGER_HAPPY  0x2c0
 #define BTN_TRIGGER_HAPPY1 0x2c0
 #define BTN_TRIGGER_HAPPY2 0x2c1
-- 
2.8.1

[PATCHv16 01/13] input.h: add BUS_CEC type

From: Hans Verkuil 

Inputs can come in over the HDMI CEC bus, so add a new type for this.

Signed-off-by: Hans Verkuil 
Acked-by: Dmitry Torokhov 
---
 include/uapi/linux/input.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 0111384..c514941 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -247,6 +247,7 @@ struct input_mask {
 #define BUS_ATARI  0x1B
 #define BUS_SPI0x1C
 #define BUS_RMI0x1D
+#define BUS_CEC0x1E

 /*
  * MT_TOOL types
-- 
2.8.1

[PATCHv16 00/13] HDMI CEC framework

From: Hans Verkuil 

Hi all,

The sixteenth version of this patchset does some final cleanup and
I'll post a pull request on the linux-media list for this patch series.

At first I didn't want to post a v16 at all, but there were just a bit
too many changes, even though each change itself was trivial.

While the pull request will be for 4.7 I think it is more likely that
it will end up in 4.8 given how late we are in the 4.7 cycle.

I dropped the RFC patches for the pulse8 and ARC/CDC support since those
aren't ready for mainlining. Same for the omap4 support patches I posted
today.

See the changelog below for more details.

The cec-ctl and cec-compliance utilities used to test the CEC framework
can be found here:

http://git.linuxtv.org/cgit.cgi/hverkuil/v4l-utils.git/log/?h=cec

Best regards,

Hans

Changes since v15
=

- Properly document cec-edid.h
- Fix various sparse/smatch warnings
- Fixed several DocBook issues
- Fixed incorrect return values in the adv drivers that caused an
  otherwise harmless WARN_ON.

Changes since v14
=
- Dropped the Samsung dts patches, these will go in via the samsung tree.
- CEC_LOG_STATUS is replaced by a debugfs status file.
- Dropped the reserved fields in the API, use versioning instead. Two
  flags field were added instead.
- Extended cec_caps with a version field.
- Dropped CEC_CAP_IS_SOURCE as it is not needed in practice.
- The adv drivers now create the CEC adapter themselves instead of leaving
  that to the bridge. It greatly simplifies the code and it was really a
  left-over from the early days of the framework.
- The CEC implementation of the adv drivers is now configured through
  a separate config option. CEC is an optional HDMI feature and you may not
  want to compile this in if your hardware hasn't hooked up the CEC pin.
- The EDID CEC helper functions have been split off into their own cec-edid
  module. You likely need them even if MEDIA_CEC is not set.
- Added missing copyright statements.
- Added RFC code for the pulse-eight USB CEC adapter.

Changes since v13
=
- Removed CEC_CAP_STATE and _VENDOR_ID
- Removed CEC_ADAP_G/S_STATE and CEC_ADAP_G/S_VENDOR_ID
- Add vendor_id to struct cec_log_addrs
- CEC_EVENT_STATE_CHANGE now reports the physical address, the logical
  address mask and the logical address type mask.
- Add the logical address mask and the logical address type mask to
  struct cec_log_addrs.
- Dropped cec_enable, instead enable/disable the adapter based on the
  physical address.
- Once a valid physical address is available and userspace or driver
  specified the requested logical address configuration the framework
  will automatically claim the needed logical addresses. It will retry
  the last used addresses first, as per the recommendation in the CEC
  specification.
- Dropped CEC power status handling: it's not clear if the kernel should
  handle that, and if it has to, whether this is the correct way.
- Dropped CEC_EVENT_PHYS_ADDR_CHANGE, this is now handled by
  CEC_EVENT_STATE_CHANGE.
- Add helper functions for manipulating physical addresses.
- Updated documentation.
- Dropped ninputs field in struct cec_caps.
- Dropped CEC_EVENT_INPUTS_CHANGE, was never used and it is unclear if it
  is needed.

Changes since v12
=
- Added driver and name fields to the cec_caps struct. Without this it was
  very difficult to tell CEC adapters apart in a human readable manner.
- Renamed CEC_CAP_IO to CEC_CAP_TRANSMIT, which better describes this
  capability. 
- Added the CEC_ADAP_LOG_STATUS to log the current status of the CEC adapter.
  Very useful when debugging.
- Added comments to the cec.c source.
- Added a timeout when waiting for a transmit to finish. Without the timeout
  the state machine could lock up when dealing with broken CEC adapter drivers
  or just unlucky situations.
- Commenting the code also found a number of bugs which have been fixed.
- Trying to poll yourself is now handled by the framework since different
  hardware would give different results. The framework will just NACK it.
- Disabling the CEC adapter doesn't clear the physical address anymore.
  This turned out to be quite painful for applications.
- Merged the CLAIM/RELEASE, G/S_MONITOR and G_PASSTHROUGH ioctls into two
  G/S_MODE ioctls. This allows you to tell the driver which initiator and
  follower modes you want, and greatly simplifies how these modes are
  handled.

Changes since v11
=
- Add a new CEC_EVENT_PHYS_ADDR_CHANGED to report when the physical address
  of the CEC adapter changes. Since the physical address is obtained from the
  EDID the application has to be informed when the kernel (or userspace for
  that matter) sets that.
- Add a new internal cec_set_phys_addr() function to change the physical
  address and post the event.
- Modified the retry-transmit mechanism: the framework will do the retry if
  the low-level driver returns a TX_STATUS error, but does no

[PATCH v4 3/7] drm/fb-helper: Add fb_deferred_io support

Hi,

On 28/04/16 18:18, Noralf TrÃ¸nnes wrote:
> This adds deferred io support to drm_fb_helper.
> The fbdev framebuffer changes are flushed using the callback
> (struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
> ensuring that it always runs in process context.
> 
> Signed-off-by: Noralf TrÃ¸nnes 
> Reviewed-by: Daniel Vetter 
> ---

Thanks for the series! Unfortunately I haven't been able to follow the
discussions properly, so I hope my questions haven't been covered earlier.

> Changes since v3:
> - Don't use forward decl, move drm_fb_helper_dirty_work()
> - Use DIV_ROUND_UP in drm_fb_helper_deferred_io()
> 
> Changes since v2:
> - FB_DEFERRED_IO is now always selected by DRM_KMS_FB_HELPER, ifdef removed
> - The drm_clip_rect utility functions are dropped, so open code it
> - docs: use & to denote structs
> 
> Changes since v1:
> - Use a dedicated worker to run the framebuffer flushing like qxl does
> - Add parameter descriptions to drm_fb_helper_deferred_io
> 
>  drivers/gpu/drm/Kconfig |   1 +
>  drivers/gpu/drm/drm_fb_helper.c | 103 
> +++-
>  include/drm/drm_fb_helper.h |  15 ++
>  3 files changed, 118 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 9e4f2f1..8e6f34b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -52,6 +52,7 @@ config DRM_KMS_FB_HELPER
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
>   select FB_CFB_IMAGEBLIT
> + select FB_DEFERRED_IO
>   help
> FBDEV helpers for KMS drivers.
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 855108e..62f849f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -84,6 +84,15 @@ static LIST_HEAD(kernel_fb_helper_list);
>   * and set up an initial configuration using the detected hardware, drivers
>   * should call drm_fb_helper_single_add_all_connectors() followed by
>   * drm_fb_helper_initial_config().
> + *
> + * If CONFIG_FB_DEFERRED_IO is enabled and &drm_framebuffer_funcs ->dirty is
> + * set, the drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit}
> + * functions will accumulate changes and schedule &fb_helper .dirty_work to 
> run
> + * right away. This worker then calls the dirty() function ensuring that it
> + * will always run in process context since the fb_*() function could be
> + * running in atomic context. If drm_fb_helper_deferred_io() is used as the

Who's calling {write,fillrect,copyarea,imageblit} in an atomic context?
That sounds like a very bad idea to me...

If this is only for accumulating changes, I think it may be better to
leave that to the driver as it may have better idea of how to accumulate.

But, of course, this is a helper, so if all the drivers use this kind of
accumulation, it makes sense =).

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/60a28cd0/attachment.sig>

[PATCH v2] drm/rockchip: vop: fix iommu crash with async atomic

After async atomic_commit callback, drm_atomic_clean_old_fb will
cleanup all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.

Fix the problem by reference the fb and unreference it when the fb
actually swap out from vop hardware.

Signed-off-by: Mark Yao 
---
Changes in v2:
- fix some format problem.

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 28596e7..8652bb1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -560,6 +560,22 @@ static void vop_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }

+static int vop_plane_prepare_fb(struct drm_plane *plane,
+   const struct drm_plane_state *new_state)
+{
+   if (plane->state->fb)
+   drm_framebuffer_reference(plane->state->fb);
+
+   return 0;
+}
+
+static void vop_plane_cleanup_fb(struct drm_plane *plane,
+const struct drm_plane_state *old_state)
+{
+   if (old_state->fb)
+   drm_framebuffer_unreference(old_state->fb);
+}
+
 static int vop_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
 {
@@ -756,6 +772,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 }

 static const struct drm_plane_helper_funcs plane_helper_funcs = {
+   .prepare_fb = vop_plane_prepare_fb,
+   .cleanup_fb = vop_plane_cleanup_fb,
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,
-- 
1.9.1

[PATCH 3/3] drm/exynos/decon5433: fix trigger configuration

2016-04-29 Thread Andrzej Hajda

It seems trigger cannot be configured too early, otherwise it does not work in
case of panel. The patch fixes also trigger flag logic, previously HW-TRIGGER
flag was cleared in case of panel - as a result panel used always software
trigger.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 7b4f699..9ae913b 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -151,11 +151,13 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
writel(val, ctx->addr + DECON_CMU);

+   if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
+   decon_setup_trigger(ctx);
+
/* lcd on and use command if */
val = VIDOUT_LCD_ON;
if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
-   decon_setup_trigger(ctx);
} else {
val |= VIDOUT_RGB_IF;
}
@@ -380,9 +382,6 @@ static void decon_swreset(struct decon_context *ctx)
writel(VIDCON1_VCLK_RUN_VDEN_DISABLE, ctx->addr + DECON_VIDCON1);
writel(CRCCTRL_CRCEN | CRCCTRL_CRCSTART_F | CRCCTRL_CRCCLKEN,
   ctx->addr + DECON_CRCCTRL);
-
-   if (ctx->out_type & IFTYPE_I80)
-   decon_setup_trigger(ctx);
 }

 static void decon_enable(struct exynos_drm_crtc *crtc)
@@ -652,9 +651,8 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)

if (ctx->out_type & IFTYPE_HDMI) {
ctx->first_win = 1;
-   ctx->out_type = IFTYPE_I80;
} else if (of_get_child_by_name(dev->of_node, "i80-if-timings")) {
-   ctx->out_type = IFTYPE_I80;
+   ctx->out_type |= IFTYPE_I80;
}

for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
-- 
1.9.1

[PATCH 2/3] drm/exynos/decon5433: do not use unnecessary software trigger

2016-04-29 Thread Andrzej Hajda

Software trigger should not be used if hardware trigger is configured.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index a835dd8..7b4f699 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -438,7 +438,8 @@ static void decon_te_irq_handler(struct exynos_drm_crtc 
*crtc)
 {
struct decon_context *ctx = crtc->ctx;

-   if (!test_bit(BIT_CLKS_ENABLED, &ctx->flags))
+   if (!test_bit(BIT_CLKS_ENABLED, &ctx->flags) ||
+   (ctx->out_type & I80_HW_TRG))
return;

if (test_and_clear_bit(BIT_WIN_UPDATED, &ctx->flags))
-- 
1.9.1

[PATCH 1/3] drm/exynos/decon5433: handle vblank in vblank interrupt

2016-04-29 Thread Andrzej Hajda

vblank should be signaled to userspace after reading framebuffers not before,
signaling it in TE interrupt looks wrong. TE triggers reading framebuffers
so it is the worst moment. Tearing is not observable because hardware prevents
it, but there are frequently skipped vblank events.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index b985b96..a835dd8 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -443,8 +443,6 @@ static void decon_te_irq_handler(struct exynos_drm_crtc 
*crtc)

if (test_and_clear_bit(BIT_WIN_UPDATED, &ctx->flags))
decon_set_bits(ctx, DECON_TRIGCON, TRIGCON_SWTRIGCMD, ~0);
-
-   drm_crtc_handle_vblank(&ctx->crtc->base);
 }

 static void decon_clear_channels(struct exynos_drm_crtc *crtc)
@@ -577,6 +575,7 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)

/* clear */
writel(val, ctx->addr + DECON_VIDINTCON1);
+   drm_crtc_handle_vblank(&ctx->crtc->base);
}

 out:
-- 
1.9.1

[PATCH] drm/rockchip: vop: Initialize vskiplines to zero

There is a path that use vskiplines with non-initialize.
That would cause vop abnormal behavior.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 8652bb1..bf55cda 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -310,7 +310,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
uint16_t vsu_mode;
uint16_t lb_mode;
uint32_t val;
-   int vskiplines;
+   int vskiplines = 0;

if (dst_w > 3840) {
DRM_ERROR("Maximum destination width (3840) exceeded\n");
-- 
1.9.1

[Bug 95203] Tonga GST/OMX/VCE encode broken since mesa: st/omx: Fix resource leak on OMX_ErrorNone

https://bugs.freedesktop.org/show_bug.cgi?id=95203

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Andy Furniss  ---
fixed mesa 4b1ea6910ee54afb30fd005eb1f8cf6f88338eda

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/1db464cc/attachment-0001.html>

[PATCH 3/3] drm/msm/mdp4: Don't manage DSI PLL regulators in MDP driver

The MDP4 driver tries to request and set voltages for regulators required
by the DSI PLLs.

Firstly, the MDP4 driver shouldn't manage the DSI regulators, this should
be handled in the DSI driver. Secondly, it shouldn't try to set a fixed
voltage for regulators. Voltage constraints should be specified on the
regulator via DT and managed by the regulator core.

Remove all the DSI PLL regulator related code from the MDP4 driver. It's
managed in the DSI driver for MSM8960/APQ8064 already.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 34 -
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h |  2 --
 2 files changed, 36 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 76e1dfb..67442d5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -50,30 +50,6 @@ static int mdp4_hw_init(struct msm_kms *kms)

mdp4_kms->rev = minor;

-   if (mdp4_kms->dsi_pll_vdda) {
-   if ((mdp4_kms->rev == 2) || (mdp4_kms->rev == 4)) {
-   ret = regulator_set_voltage(mdp4_kms->dsi_pll_vdda,
-   120, 120);
-   if (ret) {
-   dev_err(dev->dev,
-   "failed to set dsi_pll_vdda voltage: 
%d\n", ret);
-   goto out;
-   }
-   }
-   }
-
-   if (mdp4_kms->dsi_pll_vddio) {
-   if (mdp4_kms->rev == 2) {
-   ret = regulator_set_voltage(mdp4_kms->dsi_pll_vddio,
-   180, 180);
-   if (ret) {
-   dev_err(dev->dev,
-   "failed to set dsi_pll_vddio voltage: 
%d\n", ret);
-   goto out;
-   }
-   }
-   }
-
if (mdp4_kms->rev > 1) {
mdp4_write(mdp4_kms, REG_MDP4_CS_CONTROLLER0, 0x0707);
mdp4_write(mdp4_kms, REG_MDP4_CS_CONTROLLER1, 0x03073f3f);
@@ -485,16 +461,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
goto fail;
}

-   mdp4_kms->dsi_pll_vdda =
-   devm_regulator_get_optional(&pdev->dev, "dsi_pll_vdda");
-   if (IS_ERR(mdp4_kms->dsi_pll_vdda))
-   mdp4_kms->dsi_pll_vdda = NULL;
-
-   mdp4_kms->dsi_pll_vddio =
-   devm_regulator_get_optional(&pdev->dev, 
"dsi_pll_vddio");
-   if (IS_ERR(mdp4_kms->dsi_pll_vddio))
-   mdp4_kms->dsi_pll_vddio = NULL;
-
/* NOTE: driver for this regulator still missing upstream.. use
 * _get_exclusive() and ignore the error if it does not exist
 * (and hope that the bootloader left it on for us)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index b282871..c5d045d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -37,8 +37,6 @@ struct mdp4_kms {

void __iomem *mmio;

-   struct regulator *dsi_pll_vdda;
-   struct regulator *dsi_pll_vddio;
struct regulator *vdd;

struct clk *clk;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/3] drm/msm/edp: Drop regulator_set_voltage call

The eDP driver tries to set a fixed voltage for one of its regulators(vdda)
before enabling it. This shouldn't be done by the driver, the voltage
constraints should be specified on the regulator via DT and managed by
the regulator core. A driver should call regulator_set_voltage only if
it needs to change the voltage during runtime. Drop the
regulator_set_voltage call. Mention in a comment the voltage that the
regulator expects.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/edp/edp_ctrl.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c 
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 81200e9..b0c02ee 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -21,8 +21,6 @@
 #include "edp.h"
 #include "edp.xml.h"

-#define VDDA_MIN_UV180 /* uV units */
-#define VDDA_MAX_UV180 /* uV units */
 #define VDDA_UA_ON_LOAD10  /* uA units */
 #define VDDA_UA_OFF_LOAD   100 /* uA units */

@@ -67,7 +65,7 @@ struct edp_ctrl {
void __iomem *base;

/* regulators */
-   struct regulator *vdda_vreg;
+   struct regulator *vdda_vreg;/* 1.8 V */
struct regulator *lvl_vreg;

/* clocks */
@@ -326,12 +324,6 @@ static int edp_regulator_enable(struct edp_ctrl *ctrl)
 {
int ret;

-   ret = regulator_set_voltage(ctrl->vdda_vreg, VDDA_MIN_UV, VDDA_MAX_UV);
-   if (ret) {
-   pr_err("%s:vdda_vreg set_voltage failed, %d\n", __func__, ret);
-   goto vdda_set_fail;
-   }
-
ret = regulator_set_load(ctrl->vdda_vreg, VDDA_UA_ON_LOAD);
if (ret < 0) {
pr_err("%s: vdda_vreg set regulator mode failed.\n", __func__);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/3] drm/msm/dsi: Fix regulator API abuse

The voltage changing code in this driver is broken and should be
removed.  The driver sets a single, exact voltage on probe.  Unless
there is a very good reason for this (which should be documented in
comments) constraints like this need to be set via the machine
constraints, voltage setting in a driver is expected to be used in cases
where the voltage varies at runtime.

In addition client drivers should almost never be calling
regulator_can_set_voltage(), if the device needs to set a voltage it
needs to set the voltage and the regulator core will handle the case
where the regulator is fixed voltage.  If the driver simply skips
setting the voltage if it doesn't have permission then it should just
not bother in the first place.

Originally authored by Mark Brown 

Remove the min/max voltage data entries per SoC managed by the driver.
These aren't needed as we don't try to set voltages any more. Mention in
comments the voltages that each regulator expects.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi.h   |  2 --
 drivers/gpu/drm/msm/dsi/dsi_cfg.c   | 34 -
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 12 -
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c   | 13 --
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c  |  4 +--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c  |  4 +--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c |  2 +-
 7 files changed, 22 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 749fbb2..03f115f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -41,8 +41,6 @@ enum msm_dsi_phy_type {
 /* Regulators for DSI devices */
 struct dsi_reg_entry {
char name[32];
-   int min_voltage;
-   int max_voltage;
int enable_load;
int disable_load;
 };
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index e58e9b9..93c1ee0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -22,9 +22,9 @@ static const struct msm_dsi_config apq8064_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
-   {"vdda", 120, 120, 10, 100},
-   {"avdd", 300, 300, 11, 100},
-   {"vddio", 180, 180, 10, 100},
+   {"vdda", 10, 100},  /* 1.2 V */
+   {"avdd", 1, 100},   /* 3.0 V */
+   {"vddio", 10, 100}, /* 1.8 V */
},
},
.bus_clk_names = dsi_v2_bus_clk_names,
@@ -40,10 +40,10 @@ static const struct msm_dsi_config msm8974_apq8084_dsi_cfg 
= {
.reg_cfg = {
.num = 4,
.regs = {
-   {"gdsc", -1, -1, -1, -1},
-   {"vdd", 300, 300, 15, 100},
-   {"vdda", 120, 120, 10, 100},
-   {"vddio", 180, 180, 10, 100},
+   {"gdsc", -1, -1},
+   {"vdd", 15, 100},   /* 3.0 V */
+   {"vdda", 10, 100},  /* 1.2 V */
+   {"vddio", 10, 100}, /* 1.8 V */
},
},
.bus_clk_names = dsi_6g_bus_clk_names,
@@ -59,9 +59,9 @@ static const struct msm_dsi_config msm8916_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
-   {"gdsc", -1, -1, -1, -1},
-   {"vdda", 120, 120, 10, 100},
-   {"vddio", 180, 180, 10, 100},
+   {"gdsc", -1, -1},
+   {"vdda", 10, 100},  /* 1.2 V */
+   {"vddio", 10, 100}, /* 1.8 V */
},
},
.bus_clk_names = dsi_8916_bus_clk_names,
@@ -73,13 +73,13 @@ static const struct msm_dsi_config msm8994_dsi_cfg = {
.reg_cfg = {
.num = 7,
.regs = {
-   {"gdsc", -1, -1, -1, -1},
-   {"vdda", 125, 125, 10, 100},
-   {"vddio", 180, 180, 10, 100},
-   {"vcca", 100, 100, 1, 100},
-   {"vdd", 180, 180, 10, 100},
-   {"lab_reg", -1, -1, -1, -1},
-   {"ibb_reg", -1, -1, -1, -1},
+   {"gdsc", -1, -1},
+   {"vdda", 10, 100},  /* 1.25 V */
+   {"vddio", 10, 100}, /* 1.8 V */
+   {"vcca", 1, 100},   /* 1.0 V */
+   {"vdd", 10, 100},   /* 1.8 V */
+   {"lab_reg", -1, -1},
+   {"ibb_reg", -1, -1},
},
},
.bus_clk_names = dsi_6g_bus_clk_names,
diff --git a/drivers/g

[PATCH 0/3] drm/msm: Remove regulator_set_voltage calls

The MSM KMS driver calls regulator_set_voltage to set a fixed voltage in a
few places. This isn't correct API usage as explained in the commit message
of Mark Brown's original patch:

http://www.spinics.net/lists/dri-devel/msg103714.html

This patchset drops all the regultor_set_voltage calls. The first patch
adds some more clean up code to Mark's original patch.

Archit Taneja (3):
  drm/msm/dsi: Fix regulator API abuse
  drm/msm/edp: Drop regulator_set_voltage call
  drm/msm/mdp4: Don't manage DSI PLL regulators in MDP driver

 drivers/gpu/drm/msm/dsi/dsi.h   |  2 --
 drivers/gpu/drm/msm/dsi/dsi_cfg.c   | 34 -
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 12 -
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c   | 13 --
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c  |  4 +--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c  |  4 +--
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c |  2 +-
 drivers/gpu/drm/msm/edp/edp_ctrl.c  | 10 +---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 34 -
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h |  2 --
 10 files changed, 23 insertions(+), 94 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #5 from barneyman at gmx.de ---
Attachments added...

What do you mean with bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/324a5467/attachment.html>

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #4 from barneyman at gmx.de ---
Created attachment 123352
  --> https://bugs.freedesktop.org/attachment.cgi?id=123352&action=edit
xrandr output kernel 4.5.2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/8e0ef851/attachment.html>

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #3 from barneyman at gmx.de ---
Created attachment 123351
  --> https://bugs.freedesktop.org/attachment.cgi?id=123351&action=edit
Xorg.0.log kernel 4.5.2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/5b845965/attachment.html>

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #2 from barneyman at gmx.de ---
Created attachment 123350
  --> https://bugs.freedesktop.org/attachment.cgi?id=123350&action=edit
dmesg kernel 4.5.2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/dd15435a/attachment.html>

[PATCHv2 5/5] drm/i915/skl: Add support for blending modes

From: Damien Lespiau 

This patch adds support for blending modes involving
color.

V2: Add support for primary plane.
Separate out plane alpha disable functionality from per pixel
drop_alpha blend function and add another blend function case for
disabling plane alpha.

Signed-off-by: Damien Lespiau 
Signed-off-by: vandita kulkarni 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 +++
 drivers/gpu/drm/i915/intel_display.c | 47 
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  9 +--
 4 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9464ba3..4d0c39d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5515,6 +5515,10 @@ enum skl_disp_power_wells {
 #define PLANE_KEYMAX(pipe, plane)  \
_MMIO_PLANE(plane, _PLANE_KEYMAX_1(pipe), _PLANE_KEYMAX_2(pipe))

+#define PLANE_KEYMAX_ALPHA_MASK0x00ff
+#define PLANE_KEY_MASK_ALPHA_EN31
+#define PLANE_KEY_MAX_ALPHA_SHIFT  24
+
 #define _PLANE_BUF_CFG_1_B 0x7127c
 #define _PLANE_BUF_CFG_2_B 0x7137c
 #define _PLANE_BUF_CFG_1(pipe) \
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 037407f..31755f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3032,6 +3032,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   const struct drm_intel_sprite_colorkey *key =
+   &to_intel_plane_state(plane->state)->ckey;
int pipe = intel_crtc->pipe;
u32 plane_ctl, stride_div, stride;
u32 tile_height, plane_offset, plane_size;
@@ -3064,6 +3066,15 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,

WARN_ON(drm_rect_width(&plane_state->src) == 0);

+   I915_WRITE(PLANE_KEYMAX(pipe, 0), (DRM_MODE_COLOR_ALPHA_8
+   (plane_state->base.blend_mode.color)
+   << PLANE_KEY_MAX_ALPHA_SHIFT) |
+   (key->max_value & PLANE_KEYMAX_ALPHA_MASK));
+   I915_WRITE(PLANE_KEYMSK(pipe, 0),
+   (plane_state->use_plane_alpha
+   << PLANE_KEY_MASK_ALPHA_EN) |
+   (key->channel_mask & GENMASK(0, 26)));
+
if (intel_rotation_90_or_270(rotation)) {
int cpp = drm_format_plane_cpp(fb->pixel_format, 0);

@@ -3146,6 +3157,7 @@ static int intel_plane_state_check_blend(struct 
drm_plane_state *plane_state)
case DRM_BLEND_FUNC(AUTO, AUTO):
if (has_per_pixel_blending)
state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA;
+   state->use_plane_alpha = false;
break;
/* fbs without an alpha channel, or dropping the alpha channel */
case DRM_BLEND_FUNC(ONE, ZERO):
@@ -3158,6 +3170,7 @@ static int intel_plane_state_check_blend(struct 
drm_plane_state *plane_state)
state->per_pixel_alpha = DROP_ALPHA;
else
state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA;
+   state->use_plane_alpha = false;
break;
/* non pre-multiplied alpha */
case DRM_BLEND_FUNC(SRC_ALPHA, ONE_MINUS_SRC_ALPHA):
@@ -3165,6 +3178,34 @@ static int intel_plane_state_check_blend(struct 
drm_plane_state *plane_state)
state->per_pixel_alpha = DROP_ALPHA;
else
state->per_pixel_alpha = NON_PRE_MULTIPLIED_ALPHA;
+   state->use_plane_alpha = false;
+   break;
+   /* plane alpha */
+   case DRM_BLEND_FUNC(CONSTANT_ALPHA, ONE_MINUS_CONSTANT_ALPHA):
+   state->use_plane_alpha = true;
+   break;
+   /* plane alpha, pre-multiplied fb */
+   case DRM_BLEND_FUNC(CONSTANT_ALPHA,
+   ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA):
+   if (!has_per_pixel_blending)
+   state->per_pixel_alpha = DROP_ALPHA;
+   else
+   state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA;
+   /*TBD bspec check*/
+   state->use_plane_alpha = true;
+   break;
+   /* plane alpha, non pre-multiplied fb */
+   case DRM_BLEND_FUNC(CONSTANT_ALPHA_TIMES_SRC_ALPHA,
+   ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA):
+   if (!has_per_pixel_blending)
+   state->per_pixel_alpha = DROP_ALPHA;
+   else
+   state->per_pixel_alpha = NON_PRE_MULTIPLIED_ALPHA;

[PATCHv2 4/5] drm: Add an blend_color property

From: Damien Lespiau 

Add blend color property and update the
documentation for the same

V2: Add blend color support in get property.

Signed-off-by: Damien Lespiau 
Signed-off-by: vandita kulkarni 
---
 Documentation/DocBook/gpu.tmpl | 11 +--
 drivers/gpu/drm/drm_atomic.c   |  4 
 drivers/gpu/drm/drm_crtc.c |  5 +
 include/drm/drm_crtc.h |  6 ++
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index f673989..8572c9a 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
ârotationâ
BITMASK
@@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev)
CRTC that connector is attached to (atomic)


-   Plane
+   Plane
âtypeâ
ENUM | IMMUTABLE
{ "Overlay", "Primary", "Cursor" }
@@ -1953,6 +1953,13 @@ void intel_crt_init(struct drm_device *dev)
Source and destination blending factors


+   âblend_colorâ
+   Color
+   DRM_MODE_COLOR()
+   Plane
+   Blend constant color
+   
+   
DVI-I
âsubconnectorâ
ENUM
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2ead2d..20340de 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -713,6 +713,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
return -EINVAL;

state->blend_mode.func = val & GENMASK(31, 0);
+   } else if (property == config->prop_blend_color) {
+   state->blend_mode.color = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -771,6 +773,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == config->prop_blend_func) {
*val = state->blend_mode.func;
+   } else if (property == config->prop_blend_color) {
+   *val = state->blend_mode.color;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2cac5e1..65cbaea 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1592,6 +1592,11 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_blend_func = prop;

+   prop = drm_property_create_range(dev, 0, "blend_color", 0, U64_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_blend_color = prop;
+
return 0;
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 269f660..33d5845 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -95,6 +95,10 @@ enum drm_blend_factor {
DRM_BLEND_FACTOR_ONE,
DRM_BLEND_FACTOR_SRC_ALPHA,
DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
+   DRM_BLEND_FACTOR_CONSTANT_ALPHA,
+   DRM_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA,
+   DRM_BLEND_FACTOR_CONSTANT_ALPHA_TIMES_SRC_ALPHA,
+   DRM_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA,
 };

 #define DRM_BLEND_FUNC(src_factor, dst_factor) \
@@ -103,6 +107,7 @@ enum drm_blend_factor {
 #define DRM_BLEND_FUNC_DST_FACTOR(val) ((val) & 0x)

 struct drm_blend_mode {
+   uint64_t color;
uint64_t func;
 };

@@ -2145,6 +2150,7 @@ struct drm_mode_config {
struct drm_property *prop_active;
struct drm_property *prop_mode_id;
struct drm_property *prop_blend_func;
+   struct drm_property *prop_blend_color;

/* DVI-I properties */
struct drm_property *dvi_i_subconnector_property;
-- 
1.9.1

[PATCHv2 3/5] drm: Introduce DRM_MODE_COLOR()

From: Damien Lespiau 

In the hope of expressing colors in the KMS API in a consitant want,
let's introduce a ARGB 16161616 color and a few convinience macros
around it.

Signed-off-by: Damien Lespiau 
---
 include/uapi/drm/drm_mode.h | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7a7856e..203c7ab0 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -295,6 +295,40 @@ struct drm_mode_get_connector {
  */
 #define DRM_MODE_PROP_ATOMIC0x8000

+/* Color for the KMS API, ARGB (msb -> lsb) 16bits per component. */
+#define DRM_MODE_COLOR(a, r, b, g) \
+   (((__u64)(a) << 48) | ((__u64)(r) << 32) | \
+((__u64)(g) << 16) | (__u64)(b))
+
+/* Extract full precision, 8 bits, 10 bits and 12 bits components. */
+#define DRM_MODE_COLOR_ALPHA(color)(((color) >> 48) & 0x)
+#define DRM_MODE_COLOR_RED(color)  (((color) >> 32) & 0x)
+#define DRM_MODE_COLOR_BLUE(color) (((color) >> 16) & 0x)
+#define DRM_MODE_COLOR_GREEN(color)((color) & 0x)
+#define DRM_MODE_COLOR_ALPHA_8(color)  (((color) >> (48 + 8)) & 0xff)
+#define DRM_MODE_COLOR_RED_8(color)(((color) >> (32 + 8)) & 0xff)
+#define DRM_MODE_COLOR_BLUE_8(color)   (((color) >> (16 + 8)) & 0xff)
+#define DRM_MODE_COLOR_GREEN_8(color)  (((color) >>  8) & 0xff)
+#define DRM_MODE_COLOR_ALPHA_10(color) (((color) >> (48 + 6)) & 0x3ff)
+#define DRM_MODE_COLOR_RED_10(color)   (((color) >> (32 + 6)) & 0x3ff)
+#define DRM_MODE_COLOR_BLUE_10(color)  (((color) >> (16 + 6)) & 0x3ff)
+#define DRM_MODE_COLOR_GREEN_10(color) (((color) >>  6) & 0x3ff)
+#define DRM_MODE_COLOR_ALPHA_12(color) (((color) >> (48 + 4)) & 0xfff)
+#define DRM_MODE_COLOR_RED_12(color)   (((color) >> (32 + 4)) & 0xfff)
+#define DRM_MODE_COLOR_BLUE_12(color)  (((color) >> (16 + 4)) & 0xfff)
+#define DRM_MODE_COLOR_GREEN_12(color) (((color) >>  4) & 0xfff)
+
+/* Handy macros to convert a DRM_MODE_COLOR() into common precisions */
+#define DRM_MODE_COLOR_TO_ARGB_(color)  \
+   ((DRM_MODE_COLOR_ALPHA_8(color) << 24) | \
+(DRM_MODE_COLOR_RED_8(color)   << 16) | \
+(DRM_MODE_COLOR_GREEN_8(color) << 8)  | \
+DRM_MODE_COLOR_BLUE_8(color))
+#define DRM_MODE_COLOR_TO_RGB_101010(color)  \
+((DRM_MODE_COLOR_RED_10(color)  << 20) | \
+(DRM_MODE_COLOR_GREEN_10(color) << 10) | \
+DRM_MODE_COLOR_BLUE_10(color))
+
 struct drm_mode_property_enum {
__u64 value;
char name[DRM_PROP_NAME_LEN];
-- 
1.9.1

[PATCHv2 2/5] drm/i915/skl: Add blend_func to SKL/BXT sprite planes

From: Damien Lespiau 

This patch adds the blend functions, and as per the
blend function, updates the plane control register values

V2: Add blend support for all RGB formats
Fix the reg writes on plane_ctl_alpha bits.

V3: Add support support for primary and cursor planes.
fix an issue where the previous value was not
retained, change the logic to do so.

Signed-off-by: Damien Lespiau 
Signed-off-by: vandita kulkarni 
---
 drivers/gpu/drm/i915/intel_display.c | 121 +--
 drivers/gpu/drm/i915/intel_drv.h |  14 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |   6 +-
 3 files changed, 133 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c5b9687..037407f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2921,8 +2921,29 @@ static void skl_detach_scalers(struct intel_crtc 
*intel_crtc)
}
 }

-u32 skl_plane_ctl_format(uint32_t pixel_format)
+u32 skl_plane_ctl_format(uint32_t pixel_format,
+   enum per_pixel_alpha_state alpha)
 {
+   u32 plane_ctl_alpha = 0;
+
+   if (pixel_format == DRM_FORMAT_ABGR ||
+   pixel_format == DRM_FORMAT_ARGB) {
+
+   switch (alpha) {
+   case DROP_ALPHA:
+   plane_ctl_alpha = PLANE_CTL_ALPHA_DISABLE;
+   break;
+   case PRE_MULTIPLIED_ALPHA:
+   plane_ctl_alpha = PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   break;
+   case NON_PRE_MULTIPLIED_ALPHA:
+   plane_ctl_alpha = PLANE_CTL_ALPHA_HW_PREMULTIPLY;
+   break;
+   default:
+   MISSING_CASE(alpha);
+   }
+   }
+
switch (pixel_format) {
case DRM_FORMAT_C8:
return PLANE_CTL_FORMAT_INDEXED;
@@ -2938,11 +2959,11 @@ u32 skl_plane_ctl_format(uint32_t pixel_format)
 * DRM_FORMAT) for user-space to configure that.
 */
case DRM_FORMAT_ABGR:
-   return PLANE_CTL_FORMAT_XRGB_ | PLANE_CTL_ORDER_RGBX |
-   PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   return ((PLANE_CTL_FORMAT_XRGB_ | (PLANE_CTL_ORDER_RGBX
+   & (~PLANE_CTL_ALPHA_MASK))) | plane_ctl_alpha);
case DRM_FORMAT_ARGB:
-   return PLANE_CTL_FORMAT_XRGB_ |
-   PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   return ((PLANE_CTL_FORMAT_XRGB_ & ~PLANE_CTL_ALPHA_MASK)
+   | plane_ctl_alpha);
case DRM_FORMAT_XRGB2101010:
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
@@ -3031,7 +3052,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
PLANE_CTL_PIPE_GAMMA_ENABLE |
PLANE_CTL_PIPE_CSC_ENABLE;

-   plane_ctl |= skl_plane_ctl_format(fb->pixel_format);
+   plane_ctl |= skl_plane_ctl_format(fb->pixel_format,
+   plane_state->per_pixel_alpha);
plane_ctl |= skl_plane_ctl_tiling(fb->modifier[0]);
plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
plane_ctl |= skl_plane_ctl_rotation(rotation);
@@ -3087,6 +3109,69 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
POSTING_READ(PLANE_SURF(pipe, 0));
 }

+static int intel_plane_state_check_blend(struct drm_plane_state *plane_state)
+{
+   struct drm_device *dev = plane_state->state->dev;
+   struct intel_plane_state *state = to_intel_plane_state(plane_state);
+   const struct drm_framebuffer *fb = plane_state->fb;
+   const struct drm_blend_mode *mode = &state->base.blend_mode;
+   bool has_per_pixel_blending;
+
+   /*
+* We don't install the properties pre-SKL, so this is SKL+ specific
+* code for now.
+*/
+   if (INTEL_INFO(dev)->gen < 9)
+   return 0;
+
+   if (!fb)
+   return 0;
+
+   has_per_pixel_blending = fb->pixel_format == DRM_FORMAT_ABGR ||
+   fb->pixel_format == DRM_FORMAT_RGBA ||
+   fb->pixel_format == DRM_FORMAT_ARGB ||
+   fb->pixel_format == DRM_FORMAT_BGRA;
+
+   /* drop alpha for all fbs without an alpha channel */
+   if (!has_per_pixel_blending)
+   state->per_pixel_alpha = DROP_ALPHA;
+
+   switch (mode->func) {
+   /*
+* The 'AUTO' behaviour is the default and keeps compatibility with
+* kernels before the introduction of the blend_func property:
+*   - pre-multiplied alpha if the fb has an alpha channel
+*   - usual DRM_BLEND_FUNC(ONE, ZERO) otherwise
+*/
+   case DRM_BLEND_FUNC(AUTO, AUTO):
+   if (has_per_pixel_blending)
+

[PATCHv2 1/5] drm: Introduce the blend-func property

From: Damien Lespiau 

We'd like to be able to program the blending modes of display planes.
Ville suggested to use something similar to the GL blend states, which
does seem like a good idea.

For now, we only consider blend factors, but room is left for
extensions: blend equation, separate rgb/alpha blend factors, blend
color.

V2: Added the belnd func property support in get property.

Suggested-by: Ville SyrjÃ¤lÃ¤ 
Signed-off-by: Damien Lespiau 
Signed-off-by: Vandita Kulkarni 
---
 Documentation/DocBook/gpu.tmpl | 11 +--
 drivers/gpu/drm/drm_atomic.c   | 14 ++
 drivers/gpu/drm/drm_crtc.c |  5 +
 include/drm/drm_crtc.h | 20 
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1464fb2..f673989 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
ârotationâ
BITMASK
@@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev)
CRTC that connector is attached to (atomic)


-   Plane
+   Plane
âtypeâ
ENUM | IMMUTABLE
{ "Overlay", "Primary", "Cursor" }
@@ -1946,6 +1946,13 @@ void intel_crt_init(struct drm_device *dev)
CRTC that plane is attached to (atomic)


+   âblend_funcâ
+   None
+   DRM_BLEND_FUNC()
+   Plane
+   Source and destination blending factors
+   
+   
DVI-I
âsubconnectorâ
ENUM
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8ee1db8..c2ead2d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -701,6 +701,18 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == config->prop_blend_func) {
+   enum drm_blend_factor src_factor, dst_factor;
+
+   src_factor = DRM_BLEND_FUNC_SRC_FACTOR(val);
+   dst_factor = DRM_BLEND_FUNC_DST_FACTOR(val);
+
+   if (src_factor != dst_factor &&
+   (src_factor == DRM_BLEND_FACTOR_AUTO ||
+   dst_factor == DRM_BLEND_FACTOR_AUTO))
+   return -EINVAL;
+
+   state->blend_mode.func = val & GENMASK(31, 0);
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -757,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == config->prop_blend_func) {
+   *val = state->blend_mode.func;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f7fe9e1..2cac5e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1587,6 +1587,11 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create_range(dev, 0, "blend_func", 0, U32_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_blend_func = prop;
+
return 0;
 }

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6d46842..269f660 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -89,6 +89,23 @@ static inline uint64_t I642U64(int64_t val)
 #define DRM_REFLECT_X  4
 #define DRM_REFLECT_Y  5

+enum drm_blend_factor {
+   DRM_BLEND_FACTOR_AUTO,
+   DRM_BLEND_FACTOR_ZERO,
+   DRM_BLEND_FACTOR_ONE,
+   DRM_BLEND_FACTOR_SRC_ALPHA,
+   DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
+};
+
+#define DRM_BLEND_FUNC(src_factor, dst_factor) \
+   (DRM_BLEND_FACTOR_##src_factor << 16 | DRM_BLEND_FACTOR_##dst_factor)
+#define DRM_BLEND_FUNC_SRC_FACTOR(val) (((val) >> 16) & 0x)
+#define DRM_BLEND_FUNC_DST_FACTOR(val) ((val) & 0x)
+
+struct drm_blend_mode {
+   uint64_t func;
+};
+
 enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
DRM_FORCE_OFF,
@@ -1273,6 +1290,8 @@ struct drm_plane_state {
/* Plane rotation */
unsigned int rotation;

+   struct drm_blend_mode blend_mode;
+
struct drm_atomic_state *state;
 };

@@ -2125,6 +2144,7 @@ struct drm_mode_config {
struct drm_property *prop_crtc_id;
struct drm_property

[PATCHv2 0/5] Support blending modes of display planes

From: vandita kulkarni 

The below patches support plane and pixel blending
by adding two properties blend_func and blend_color.
As per Damien's initial patches, this design based on 
OpenGL's blend equations is suggested by Ville.
All the below patches are tested on BXT android platform.

V2: Squashed all the blend color related patches to one
single patch and blend func related pathces into one single
patch.

The initial kernel patches from damien can be found at
https://github.com/dlespiau/linux/commits/20150708-alpha-blending
Damien Lespiau (5):
  drm: Introduce the blend-func property
  drm/i915/skl: Add blend_func to SKL/BXT sprite planes
  drm: Introduce DRM_MODE_COLOR()
  drm: Add an blend_color property
  drm/i915/skl: Add support for blending modes

The initial version of kms_blend, igt by Damien
can be found at
https://github.com/dlespiau/intel-gpu-tools/commits/20150613-blend


Damien Lespiau (5):
  drm: Introduce the blend-func property
  drm/i915/skl: Add blend_func to SKL/BXT sprite planes
  drm: Introduce DRM_MODE_COLOR()
  drm: Add an blend_color property
  drm/i915/skl: Add support for blending modes

 Documentation/DocBook/gpu.tmpl   |  18 +++-
 drivers/gpu/drm/drm_atomic.c |  18 
 drivers/gpu/drm/drm_crtc.c   |  10 +++
 drivers/gpu/drm/i915/i915_reg.h  |   4 +
 drivers/gpu/drm/i915/intel_display.c | 168 +--
 drivers/gpu/drm/i915/intel_drv.h |  17 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |  15 +++-
 include/drm/drm_crtc.h   |  26 ++
 include/uapi/drm/drm_mode.h  |  34 +++
 9 files changed, 298 insertions(+), 12 deletions(-)

-- 
1.9.1

[Bug 117171] Radeon GPU lockup in X windows after resuming from blank screen

2016-04-29 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=117171

--- Comment #3 from Erik Brangs  ---
The problem might be related to DPMS: I haven't seen any freezes after
deactivating DPMS in xscreensaver.

When I use DPMS with "Standby" in xscreensaver and set the times for "Suspend"
and "Off" to a high value so that they won't be triggered, the problem still
occurs.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[GIT PULL v2] drm-hisilicon-next for 4.7

2016-04-29 Thread Dave Airlie

>
> V2 has fixed the module compilation error and warnings in this commit:
> 3d76c7e5bbdd drm/hisilicon: Add designware dsi encoder driver
>
> Please help to try and let me know if there is any problem.

I'm still seeing the bit cast warning, it's due to using MASK(32),
this is pretty much
undefined as you do ((1U << 32) - 1) on 32-bit system. BIT_ULL might be a better
choice.

I'm also seeing a linker error
ERROR: "__aeabi_uldivmod"
[drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.ko] undefined!

which to means a missing div_u64 macro somewhere, probably in dsi_calc_phy_rate.

Dave.

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.  Can you bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/95a30b1c/attachment.html>

[RFC v2 5/8] drm/fence: add in-fences support

2016-04-29 Thread Greg Hackmann

On 04/26/2016 11:39 PM, Daniel Vetter wrote:
>> A (per-CRTC?) array of fences would be more flexible.  And even in the cases
>> where you could make a 1-to-1 mapping between planes and fences, it's not
>> that much more work for userspace to assemble those fences into an array
>> anyway.
>
> I'm ok with an array too if that's what you folks prefer (it's meant to be
> used by you after all). I just don't want just 1 fence for the entire op,
> forcing userspace to first merge them all together. That seems silly.
>
> One side-effect of that is that we'd also have to rework all the internal
> bits and move fences around in atomic. Which means change a pile of
> drivers. Not sure that's worth it, but I'd be ok either way really.
> -Daniel
>

It's not a strong preference on my end.  The 1:1 plane-to-layer mapping 
breaks down somewhat on hardware where you need to split large 
hwcomposer layers across multiple DRM planes.

That said, you can force that case to fit by just dup()ing the fence a 
bunch of times or arbitrarily picking one of the planes to assign the 
fence to.  Either is kludgey, but I can't argue it's kludgey enough to 
justify refactoring a bunch of existing driver code.

[PATCH] Revert "drm/omap: no need to select OMAP2_DSS"



On 28/04/16 15:42, Peter Ujfalusi wrote:
> This reverts commit 1c278e5e3718d15475ec08ee2135f37a6b13361c.
> 
> If DRM_OMAP does not select OMAP2_DSS it is possible to build a kernel with
> DRM_OMAP only and not selecting OMAP2_DSS. Since omapdrm depends on
> OMAP2_DSS this will result on broken kernel build.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/omapdrm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
> index 73241c4eb7aa..336ad4de9981 100644
> --- a/drivers/gpu/drm/omapdrm/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/Kconfig
> @@ -2,6 +2,7 @@ config DRM_OMAP
>   tristate "OMAP DRM"
>   depends on DRM
>   depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> + select OMAP2_DSS
>   select DRM_KMS_HELPER
>   select DRM_KMS_FB_HELPER
>   select FB_SYS_FILLRECT
> 

Thanks, queued for 4.7.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/521c88f0/attachment.sig>

[PATCH] drm/omap: Remove deprecated regulator_can_change_voltage() usage


On 28/04/16 15:42, Peter Ujfalusi wrote:
> regulator_can_change_voltage() is deprecated and it's use is not necessary
> as commit:
> 6a0028b3dd67b regulator: Deprecate regulator_can_change_voltage()
> describers it clearly.
> As there is no practical use of it it can be removed.
> At this point the regulator_set_voltage() calls can not be removed as the
> DT data need to be fixed first.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c   | 12 +---
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +---
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12 +---
>  3 files changed, 15 insertions(+), 21 deletions(-)

Thanks, queued for 4.7.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/b7fabc03/attachment.sig>

[Intel-gfx] i915 ERRORs and WARN_ON()s

2016-04-29 Thread David Weinehall

On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote:
> Hi,
> 
> > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
> > tracking bugs in drm/i915. It's your choice to not create an account
> > there, but please, don't expect us to work as a proxy between you and
> > bugzilla either. It's a much bigger and unscalable inconvenience for us
> > than it is for you to create that account.
> 
> Hu? I don't quite get it. Communicating via email is an unscalable
> inconvenience? So, if I asked you to create an account with my todo tracker
> instead, would that be more scalable and convenient? Using everyone's
> software of choice instead of my own most certainly is neither scalable nor
> convenient for me at all.

I think you're missing the point here. First of all, your bug report
isn't the only bug report. If all bug reports were posted here rather
than reported in our bug tracker, it would definitely be more likely
that some bugs would get lost. It works for small projects with a low
influx of bug reports, but it's less convenient for larger projects.
This is the scalability factor.

Second of all, convenience. Your convenience, while of course a
consideration, isn't the primary concern. The convenience of the
developers is.  You're reporting one bug, but the developers here
have to keep track of, and fix, hundreds (and that's on top of
new features, support for new platforms, test cases, and performance
improvements).

If we were asking for support for software you develop, you'd obviously
be the one to set the rules (and yes, that includes your TODO tracker,
closed forums or what not). Reporting bugs in a bug tracking system
isn't exactly a novelty. Rather the opposite.

Kind regards, David Weinehall

[Bug 95203] Tonga GST/OMX/VCE encode broken since mesa: st/omx: Fix resource leak on OMX_ErrorNone

https://bugs.freedesktop.org/show_bug.cgi?id=95203

--- Comment #2 from Andy Furniss  ---
(In reply to Emil Velikov from comment #1)
> Should be resolved with https://patchwork.freedesktop.org/patch/84551/

Yes, that fixes it, thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/a1dd260c/attachment-0001.html>

[Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

2016-04-29 Thread Ville Syrjälä

On Fri, Apr 29, 2016 at 02:59:13PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau 
> 
> We'd like to be able to program the blending modes of display planes.
> Ville suggested to use something similar to the GL blend states, which
> does seem like a good idea.
> 
> For now, we only consider blend factors, but room is left for
> extensions: blend equation, separate rgb/alpha blend factors, blend
> color.
> 
> V2: Added the belnd func property support in get property.
> 
> Suggested-by: Ville SyrjÃ¤lÃ¤ 
> Signed-off-by: Damien Lespiau 
> Signed-off-by: Vandita Kulkarni 
> ---
>  Documentation/DocBook/gpu.tmpl | 11 +--
>  drivers/gpu/drm/drm_atomic.c   | 14 ++
>  drivers/gpu/drm/drm_crtc.c |  5 +
>  include/drm/drm_crtc.h | 20 
>  4 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 1464fb2..f673989 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
>   Description/Restrictions
>   
>   
> - DRM
> + DRM
>   Generic
>   ârotationâ
>   BITMASK
> @@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev)
>   CRTC that connector is attached to (atomic)
>   
>   
> - Plane
> + Plane
>   âtypeâ
>   ENUM | IMMUTABLE
>   { "Overlay", "Primary", "Cursor" }
> @@ -1946,6 +1946,13 @@ void intel_crt_init(struct drm_device *dev)
>   CRTC that plane is attached to (atomic)
>   
>   
> + âblend_funcâ
> + None
> + DRM_BLEND_FUNC()
> + Plane
> + Source and destination blending factors
> + 
> + 
>   DVI-I
>   âsubconnectorâ
>   ENUM
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8ee1db8..c2ead2d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -701,6 +701,18 @@ int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property) {
>   state->rotation = val;
> + } else if (property == config->prop_blend_func) {
> + enum drm_blend_factor src_factor, dst_factor;
> +
> + src_factor = DRM_BLEND_FUNC_SRC_FACTOR(val);
> + dst_factor = DRM_BLEND_FUNC_DST_FACTOR(val);
> +
> + if (src_factor != dst_factor &&
> + (src_factor == DRM_BLEND_FACTOR_AUTO ||
> + dst_factor == DRM_BLEND_FACTOR_AUTO))
> + return -EINVAL;
> +
> + state->blend_mode.func = val & GENMASK(31, 0);
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -757,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_h;
>   } else if (property == config->rotation_property) {
>   *val = state->rotation;
> + } else if (property == config->prop_blend_func) {
> + *val = state->blend_mode.func;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f7fe9e1..2cac5e1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1587,6 +1587,11 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create_range(dev, 0, "blend_func", 0, U32_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_blend_func = prop;
> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 6d46842..269f660 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -89,6 +89,23 @@ static inline uint64_t I642U64(int64_t val)
>  #define DRM_REFLECT_X4
>  #define DRM_REFLECT_Y5
>  
> +enum drm_blend_factor {
> + DRM_BLEND_FACTOR_AUTO,
> + DRM_BLEND_FACTOR_ZERO,
> + DRM_BLEND_FACTOR_ONE,
> + DRM_BLEND_FACTOR_SRC_ALPHA,
> + DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,

Based on what I remember of the earlier discussion I don't think these
are quite enough. We could want some way to deal with the constant alpha
as well. Hmm. I think I need to refresh my brain a bit on this before I
can say anything really.

Also IIRC I was thinking that the premult vs. non-premult would be a
separate thing outside the blend equation. That's how we have it some
hw at least AFAIK, so be shoving it all into the blend func we may
lose certain combinations. But I suppose that's not a real problem,

[Bug 95203] Tonga GST/OMX/VCE encode broken since mesa: st/omx: Fix resource leak on OMX_ErrorNone

https://bugs.freedesktop.org/show_bug.cgi?id=95203

--- Comment #1 from Emil Velikov  ---
Should be resolved with https://patchwork.freedesktop.org/patch/84551/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/180e0a79/attachment.html>

[PATCH] Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

2016-04-29 Thread Robin Murphy

This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50.

There is apparently something amiss with the way the TTM code handles
DMA buffers, which the above commit was attempting to work around for
arm64 systems with non-coherent PCI. Unfortunately, this completely
breaks systems *with* coherent PCI (which appear to be the majority).

Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
a machine with a PCI GPU having coherent dma_map_ops (in this case a
7600GT card plugged into an ARM Juno board) results in a fatal crash:

[2.803438] nouveau :06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo 
ffc976141c00
[2.897662] Unable to handle kernel NULL pointer dereference at virtual 
address 01ac
[2.897666] pgd = ff8008e0
[2.897675] [01ac] *pgd=0009e003, *pud=0009e003, 
*pmd=
[2.897680] Internal error: Oops: 9645 [#1] PREEMPT SMP
[2.897685] Modules linked in:
[2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
[2.897694] Hardware name: ARM Juno development board (r1) (DT)
[2.897699] task: ffc9768a ti: ffc9768a8000 task.ti: 
ffc9768a8000
[2.897711] PC is at __memcpy+0x7c/0x180
[2.897719] LR is at OUT_RINGp+0x34/0x70
[2.897724] pc : [] lr : [] pstate: 
8045
[2.897726] sp : ffc9768ab360
[2.897732] x29: ffc9768ab360 x28: 0001
[2.897738] x27: ffc97624c000 x26: 
[2.897744] x25: 0080 x24: 6c00
[2.897749] x23: 0005 x22: ffc97624c010
[2.897755] x21: 0004 x20: 0004
[2.897761] x19: ffc9763da000 x18: ffc976b2491c
[2.897766] x17: 0007 x16: 0006
[2.897771] x15: 0001 x14: 0001
[2.89] x13: 00e31b70 x12: ffc9768a0080
[2.897783] x11:  x10: fb00
[2.897788] x9 :  x8 : 
[2.897793] x7 :  x6 : 01ac
[2.897799] x5 :  x4 : 
[2.897804] x3 : 0010 x2 : 0010
[2.897810] x1 : ffc97624c010 x0 : 01ac
...
[2.898494] Call trace:
[2.898499] Exception stack(0xffc9768ab1a0 to 0xffc9768ab2c0)
[2.898506] b1a0: ffc9763da000 0004 ffc9768ab360 
ff80083465fc
[2.898513] b1c0: ffc976801e00 ffc9762b8000 ffc9768ab1f0 
ff80080ec158
[2.898520] b1e0: ffc9768ab230 ff8008496d04 ffc975ce6d80 
ffc9768ab36e
[2.898527] b200: ffc9768ab36f ffc9768ab29d ffc9768ab29e 
ffc9768a
[2.898533] b220: ffc9768ab250 ff80080e70c0 ffc9768ab270 
ff8008496e44
[2.898540] b240: 01ac ffc97624c010 0010 
0010
[2.898546] b260:   01ac 

[2.898552] b280:   fb00 

[2.898558] b2a0: ffc9768a0080 00e31b70 0001 
0001
[2.898566] [] __memcpy+0x7c/0x180
[2.898574] [] nv04_fbcon_imageblit+0x1d4/0x2e8
[2.898582] [] nouveau_fbcon_imageblit+0xd8/0xe0
[2.898591] [] soft_cursor+0x154/0x1d8
[2.898598] [] bit_cursor+0x4fc/0x538
[2.898605] [] fbcon_cursor+0x134/0x1a8
[2.898613] [] hide_cursor+0x38/0xa0
[2.898620] [] redraw_screen+0x120/0x228
[2.898628] [] fbcon_prepare_logo+0x370/0x3f8
[2.898635] [] fbcon_init+0x350/0x560
[2.898641] [] visual_init+0xac/0x108
[2.898648] [] do_bind_con_driver+0x1c4/0x3a8
[2.898655] [] do_take_over_console+0x174/0x1e8
[2.898662] [] do_fbcon_takeover+0x74/0x100
[2.898669] [] fbcon_event_notify+0x8cc/0x920
[2.898680] [] notifier_call_chain+0x50/0x90
[2.898685] [] __blocking_notifier_call_chain+0x4c/0x90
[2.898691] [] blocking_notifier_call_chain+0x14/0x20
[2.898696] [] fb_notifier_call_chain+0x1c/0x28
[2.898703] [] register_framebuffer+0x1cc/0x2e0
[2.898712] [] drm_fb_helper_initial_config+0x288/0x3e8
[2.898719] [] nouveau_fbcon_init+0xe0/0x118
[2.898727] [] nouveau_drm_load+0x268/0x890
[2.898734] [] drm_dev_register+0xbc/0xc8
[2.898740] [] drm_get_pci_dev+0xa0/0x180
[2.898747] [] nouveau_drm_probe+0x1a0/0x1e0
[2.898755] [] pci_device_probe+0x98/0x110
[2.898763] [] driver_probe_device+0x204/0x2b0
[2.898770] [] __driver_attach+0xac/0xb0
[2.898777] [] bus_for_each_dev+0x60/0xa0
[2.898783] [] driver_attach+0x20/0x28
[2.898789] [] bus_add_driver+0x1d0/0x238
[2.898796] [] driver_register+0x60/0xf8
[2.898802] [] __pci_register_driver+0x3c/0x48
[2.898809] [] drm_pci_init+0xf4/0x120
[2.898818] [] nouveau_drm_init+0x21c/0x230
[2.898825] [] do_one_initcall+0x8c/0x190
[2.898832] [] kernel_init_freeable+0x14c/0x1f0
[2.898839] [] kernel_init+0x10/0x100
[

[PATCH] drm/rockchip: vop: fix iommu crash with async atomic

On Async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.

Reference the fb and unreference it when the fb actuall swap out
from vop hardware.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 28596e7..38c4de9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -560,6 +560,22 @@ static void vop_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }

+static int vop_plane_prepare_fb(struct drm_plane *plane,
+const struct drm_plane_state *new_state)
+{
+   if (plane->state->fb)
+   drm_framebuffer_reference(plane->state->fb);
+
+   return 0;
+}
+
+static void vop_plane_cleanup_fb(struct drm_plane *plane,
+ const struct drm_plane_state *old_state)
+{
+   if (old_state->fb)
+   drm_framebuffer_unreference(old_state->fb);
+}
+
 static int vop_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
 {
@@ -756,6 +772,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 }

 static const struct drm_plane_helper_funcs plane_helper_funcs = {
+   .prepare_fb = vop_plane_prepare_fb,
+   .cleanup_fb = vop_plane_cleanup_fb,
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,
-- 
1.9.1

[Bug 95206] Display port bandwidth regression

https://bugs.freedesktop.org/show_bug.cgi?id=95206

Bug ID: 95206
Summary: Display port bandwidth regression
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel at lists.freedesktop.org
Reporter: barneyman at gmx.de

Hi,

I have a mobile laptop (Dell Precision M4600) with an external monitor (Dell
U2414H) connected via display port.

Starting with mainline kernel 4.5.x I'm unable to connect the monitor with mode
(1920x1080p), instead the highest available option is 1920x1080i (interlaced)
which produces heavy flickering on the monitor and makes it unable to use at
all. Forcing the monitor into 1920x1080p (using xrandr --newmode, --addmode and
--mode) causes a total signal loss, however forcing the monitor into
1920x1080p at 30hz makes the monitor available again. If I connect the monitor
using DVI/HDMI 1080p at 60hz works without any problems.

So I think the problem might be that the maximum bandwidth of the display port
is reduced compared to the previous version.

Using kernel 4.4.8 the monitor is connected with 1080p using DP as expected
again. So it's definitely a regression introduced in kernel 4.5.

As a side note: the Ubuntu 16.04 kernel (4.4.0-21.37) also has this display
port problem, but as far as I know the ubuntu devs have backported large
portions of the 4.5 radeon patches.

If you need any further information (dmesg, xrandr output), don't hesitate to
ask...

Kind regards,
Christian

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/b5b58f88/attachment-0001.html>

[RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

From: Hans Verkuil 

As long as there is a valid physical address in the EDID and the omap
CEC support is enabled, then we keep ls_oe_gpio on to ensure the CEC
signal is passed through the tpd12s015.

Signed-off-by: Hans Verkuil 
Suggested-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 916a899..efbba23 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -16,6 +16,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 

@@ -65,6 +66,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev,
return;

gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
+   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);

dst->src = NULL;
dssdev->dst = NULL;
@@ -142,6 +144,7 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
+   bool valid_phys_addr = 0;
int r;

if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
@@ -151,7 +154,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,

r = in->ops.hdmi->read_edid(in, edid, len);

-   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
+#ifdef CONFIG_OMAP2_DSS_HDMI_CEC
+   /*
+* In order to support CEC this pin should remain high
+* as long as the EDID has a valid physical address.
+*/
+   valid_phys_addr =
+   cec_get_edid_phys_addr(edid, r, NULL) != CEC_PHYS_ADDR_INVALID;
+#endif
+   gpiod_set_value_cansleep(ddata->ls_oe_gpio, valid_phys_addr);

return r;
 }
-- 
2.8.1

[RFC PATCH 2/3] omap4: add CEC support

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/omap4-panda-a4.dts   |   2 +-
 arch/arm/boot/dts/omap4-panda-es.dts   |   2 +-
 arch/arm/boot/dts/omap4.dtsi   |   5 +-
 drivers/gpu/drm/omapdrm/dss/Kconfig|   8 +
 drivers/gpu/drm/omapdrm/dss/Makefile   |   3 +
 drivers/gpu/drm/omapdrm/dss/hdmi.h |  62 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  39 +++-
 drivers/gpu/drm/omapdrm/dss/hdmi_cec.c | 329 +
 8 files changed, 441 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi_cec.c

diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts 
b/arch/arm/boot/dts/omap4-panda-a4.dts
index 78d3631..f0c1020 100644
--- a/arch/arm/boot/dts/omap4-panda-a4.dts
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -13,7 +13,7 @@
 /* Pandaboard Rev A4+ have external pullups on SCL & SDA */
 &dss_hdmi_pins {
pinctrl-single,pins = <
-   OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* 
hdmi_cec.hdmi_cec */
+   OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
hdmi_cec.hdmi_cec */
OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
hdmi_scl.hdmi_scl */
OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
hdmi_sda.hdmi_sda */
>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 119f8e6..940fe4f 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,7 +34,7 @@
 /* PandaboardES has external pullups on SCL & SDA */
 &dss_hdmi_pins {
pinctrl-single,pins = <
-   OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* 
hdmi_cec.hdmi_cec */
+   OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
hdmi_cec.hdmi_cec */
OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
hdmi_scl.hdmi_scl */
OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
hdmi_sda.hdmi_sda */
>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2bd9c83..1bb490f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -1006,8 +1006,9 @@
reg = <0x58006000 0x200>,
  <0x58006200 0x100>,
  <0x58006300 0x100>,
- <0x58006400 0x1000>;
-   reg-names = "wp", "pll", "phy", "core";
+ <0x58006400 0x900>,
+ <0x58006D00 0x100>;
+   reg-names = "wp", "pll", "phy", "core", "cec";
interrupts = ;
status = "disabled";
ti,hwmods = "dss_hdmi";
diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig 
b/drivers/gpu/drm/omapdrm/dss/Kconfig
index d1fa730..69638e9 100644
--- a/drivers/gpu/drm/omapdrm/dss/Kconfig
+++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
@@ -71,9 +71,17 @@ config OMAP4_DSS_HDMI
bool "HDMI support for OMAP4"
 default y
select OMAP2_DSS_HDMI_COMMON
+   select MEDIA_CEC_EDID
help
  HDMI support for OMAP4 based SoCs.

+config OMAP2_DSS_HDMI_CEC
+   bool "Enable HDMI CEC support for OMAP4"
+   depends on OMAP4_DSS_HDMI && MEDIA_CEC
+   default y
+   ---help---
+ When selected the HDMI transmitter will support the CEC feature.
+
 config OMAP5_DSS_HDMI
bool "HDMI support for OMAP5"
default n
diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile 
b/drivers/gpu/drm/omapdrm/dss/Makefile
index b651ec9..37eb597 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -10,6 +10,9 @@ omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
 omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
 omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \
hdmi_phy.o
+ifeq ($(CONFIG_OMAP2_DSS_HDMI_CEC),y)
+  omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_cec.o
+endif
 omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
 omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
 ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index 53616b0..7cf8a91 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "dss.h"

@@ -83,6 +84,31 @@
 #define HDMI_TXPHY_PAD_CFG_CTRL0xC
 #define HDMI_TXPHY_BIST_CONTROL0x1C

+/* HDMI CEC */
+#define HDMI_CEC_DEV_ID 0x0
+#define HDMI_CEC_SPEC   0x4
+#define HDMI_CEC_DBG_3  0x1C
+#define HDMI_CEC_TX_INIT0x20
+#define HDMI_CEC_TX

[RFC PATCH 1/3] drm/omap: fix OMAP4 hdmi_core_powerdown_disable()

From: Tomi Valkeinen 

hdmi_core_powerdown_disable() is supposed to disable HDMI core's
power-down mode. However, the function sets the power-down bit to 0,
which means "enable power-down".

This hasn't caused any issues as the PD seems to affect only interrupts
from HDMI core, and none of those interrupts are used at the moment. CEC
functionality requires core interrupts, and the PD mode needs to be
fixed.

This patch fixes hdmi_core_powerdown_disable() to actually disable the
PD mode.

Signed-off-by: Tomi Valkeinen 
Reported-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
index fa72e73..ef3afe9 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
@@ -211,7 +211,7 @@ static void hdmi_core_init(struct hdmi_core_video_config 
*video_cfg)
 static void hdmi_core_powerdown_disable(struct hdmi_core_data *core)
 {
DSSDBG("Enter hdmi_core_powerdown_disable\n");
-   REG_FLD_MOD(core->base, HDMI_CORE_SYS_SYS_CTRL1, 0x0, 0, 0);
+   REG_FLD_MOD(core->base, HDMI_CORE_SYS_SYS_CTRL1, 0x1, 0, 0);
 }

 static void hdmi_core_swreset_release(struct hdmi_core_data *core)
-- 
2.8.1

[RFC PATCH 0/3] OMAP4 HDMI CEC support

From: Hans Verkuil 

This patch series sits on top of my earlier HDMI CEC framework:

http://www.spinics.net/lists/linux-media/msg99847.html

It is an RFC patch for now as I want to clean up hdmi_cec a bit more
and do a bit more testing.

Many thanks to Tomi for finding obscure problems in the omap4 drivers
that prevented CEC from working on my pandaboard.

Feedback is welcome!

Regards,

Hans

Hans Verkuil (2):
  omap4: add CEC support
  encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

Tomi Valkeinen (1):
  drm/omap: fix OMAP4 hdmi_core_powerdown_disable()

 arch/arm/boot/dts/omap4-panda-a4.dts   |   2 +-
 arch/arm/boot/dts/omap4-panda-es.dts   |   2 +-
 arch/arm/boot/dts/omap4.dtsi   |   5 +-
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   |  13 +-
 drivers/gpu/drm/omapdrm/dss/Kconfig|   8 +
 drivers/gpu/drm/omapdrm/dss/Makefile   |   3 +
 drivers/gpu/drm/omapdrm/dss/hdmi.h |  62 +++-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  39 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c   |   2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi_cec.c | 329 +
 10 files changed, 454 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi_cec.c

-- 
2.8.1

[GIT PULL] drm/arcpgu: use dedicated memory area for frame buffer

2016-04-29 Thread Alexey Brodkin

Hi Dave,

Please pull this mini-series that allows ARC PGU to use
dedicated memory location as framebuffer backing storage.

v2 of that series was reviewed here
https://lists.freedesktop.org/archives/dri-devel/2016-April/106279.html

It is based on top of today's drm-next branch.

Best regards,
Alexey

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

Â  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:

Â  https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
topic-arcpgu-updates

for you to fetch changes up to cb2ad5e5339c5122166265cea579cc6a356d46de:

Â  ARC: [axs10x] Specify reserved memory for frame buffer (2016-04-29 14:34:13 
+0300)


Alexey Brodkin (2):
Â Â Â Â Â Â drm/arcpgu: use dedicated memory area for frame buffer
Â Â Â Â Â Â ARC: [axs10x] Specify reserved memory for frame buffer

Â arch/arc/boot/dts/axc001.dtsiÂ Â Â Â Â | 22 --
Â arch/arc/boot/dts/axc003.dtsiÂ Â Â Â Â | 14 ++
Â arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
Â arch/arc/boot/dts/axs10x_mb.dtsiÂ Â |Â Â 2 +-
Â drivers/gpu/drm/arc/arcpgu_drv.cÂ Â |Â Â 6 ++
Â 5 files changed, 55 insertions(+), 3 deletions(-)

[PATCH] drm/gem: support BO freeing without dev->struct_mutex

Finally all the core gem and a lot of drivers are entirely free of
dev->struct_mutex depencies, and we can start to have an entirely
lockless unref path.

To make sure that no one who touches the core code accidentally breaks
existing drivers which still require dev->struct_mutex I've made the
might_lock check unconditional.

While at it de-inline the ref/unref functions, they've become a bit
too big.

v2: Make it not leak like a sieve.

v3: Review from Lucas:
- drop != NULL in pointer checks.
- fixup copypasted kerneldoc to actually match the functions.

v4:
Add __drm_gem_object_unreference as a fastpath helper for drivers who
abolished dev->struct_mutex, requested by Chris.

Cc: Chris Wilson 
Cc: Alex Deucher 
Cc: Lucas Stach 
Reviewed-by: Lucas Stach 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c | 54 ++-
 include/drm/drmP.h| 15 ++---
 include/drm/drm_gem.h | 48 +
 3 files changed, 80 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 25dac31eef37..750d8975c318 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -806,12 +806,64 @@ drm_gem_object_free(struct kref *kref)

WARN_ON(!mutex_is_locked(&dev->struct_mutex));

-   if (dev->driver->gem_free_object != NULL)
+   if (dev->driver->gem_free_object_unlocked)
+   dev->driver->gem_free_object_unlocked(obj);
+   else if (dev->driver->gem_free_object)
dev->driver->gem_free_object(obj);
 }
 EXPORT_SYMBOL(drm_gem_object_free);

 /**
+ * drm_gem_object_unreference_unlocked - release a GEM BO reference
+ * @obj: GEM buffer object
+ *
+ * This releases a reference to @obj. Callers must not hold the
+ * dev->struct_mutex lock when calling this function.
+ *
+ * See also __drm_gem_object_unreference().
+ */
+void
+drm_gem_object_unreference_unlocked(struct drm_gem_object *obj)
+{
+   struct drm_device *dev;
+
+   if (!obj)
+   return;
+
+   dev = obj->dev;
+   might_lock(&dev->struct_mutex);
+
+   if (dev->driver->gem_free_object)
+   kref_put(&obj->refcount, drm_gem_object_free);
+   else if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
+   &dev->struct_mutex))
+   mutex_unlock(&dev->struct_mutex);
+}
+EXPORT_SYMBOL(drm_gem_object_unreference_unlocked);
+
+/**
+ * drm_gem_object_unreference - release a GEM BO reference
+ * @obj: GEM buffer object
+ *
+ * This releases a reference to @obj. Callers must hold the dev->struct_mutex
+ * lock when calling this function, even when the driver doesn't use
+ * dev->struct_mutex for anything.
+ *
+ * For drivers not encumbered with legacy locking use
+ * drm_gem_object_unreference_unlocked() instead.
+ */
+void
+drm_gem_object_unreference(struct drm_gem_object *obj)
+{
+   if (obj) {
+   WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
+
+   kref_put(&obj->refcount, drm_gem_object_free);
+   }
+}
+EXPORT_SYMBOL(drm_gem_object_unreference);
+
+/**
  * drm_gem_vm_open - vma->ops->open implementation for GEM
  * @vma: VM area structure
  *
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c81dd2250fc6..bd7b262d7af0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -580,12 +580,21 @@ struct drm_driver {
void (*debugfs_cleanup)(struct drm_minor *minor);

/**
-* Driver-specific constructor for drm_gem_objects, to set up
-* obj->driver_private.
+* @gem_free_object: deconstructor for drm_gem_objects
 *
-* Returns 0 on success.
+* This is deprecated and should not be used by new drivers. Use
+* @gem_free_object_unlocked instead.
 */
void (*gem_free_object) (struct drm_gem_object *obj);
+
+   /**
+* @gem_free_object_unlocked: deconstructor for drm_gem_objects
+*
+* This is for drivers which are not encumbered with dev->struct_mutex
+* legacy locking schemes. Use this hook instead of @gem_free_object.
+*/
+   void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
+
int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b3e11ab8757..408d6c47d98b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -200,47 +200,29 @@ drm_gem_object_reference(struct drm_gem_object *obj)
 }

 /**
- * drm_gem_object_unreference - release a GEM BO reference
+ * __drm_gem_object_unreference - raw function to release a GEM BO reference
  * @obj: GEM buffer object
  *
- * This releases a reference to @obj. Callers must hold the dev->struct_mutex
- * lock when calling this function, even when the driver doesn't use
- * dev->struct_

[PATCH v3] drm/rockchip: support non-iommu buffer path

Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, the would help the debug.

Signed-off-by: Mark Yao 
---
Changes in v3
- fix conflict with other iommu patch.
Changes in v2
Advised by Heiko Stuebner
- use more suitable message print.

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 64 +
 1 file changed, 46 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 1e2d88b..0bd1cea 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -36,6 +36,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0

+static bool is_support_iommu = true;
+
 /*
  * Attach a (component) device to the shared drm dma mapping from master drm
  * device.  This is used by the VOPs to map GEM buffers to a common DMA
@@ -47,6 +49,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
int ret;

+   if (!is_support_iommu)
+   return 0;
+
ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
@@ -59,6 +64,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   if (!is_support_iommu)
+   return;
+
arm_iommu_detach_device(dev);
 }

@@ -152,23 +160,26 @@ static int rockchip_drm_load(struct drm_device *drm_dev, 
unsigned long flags)
goto err_config_cleanup;
}

-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(&platform_bus_type, 0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
+   if (is_support_iommu) {
+   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
+   mapping = arm_iommu_create_mapping(&platform_bus_type,
+  0x,
+  SZ_2G);
+   if (IS_ERR(mapping)) {
+   ret = PTR_ERR(mapping);
+   goto err_config_cleanup;
+   }

-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
+   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto err_release_mapping;

-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));

-   ret = arm_iommu_attach_device(dev, mapping);
-   if (ret)
-   goto err_release_mapping;
+   ret = arm_iommu_attach_device(dev, mapping);
+   if (ret)
+   goto err_release_mapping;
+   }

/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
@@ -218,7 +229,8 @@ static int rockchip_drm_load(struct drm_device *drm_dev, 
unsigned long flags)
if (ret)
goto err_vblank_cleanup;

-   arm_iommu_release_mapping(mapping);
+   if (is_support_iommu)
+   arm_iommu_release_mapping(mapping);
return 0;
 err_vblank_cleanup:
drm_vblank_cleanup(drm_dev);
@@ -227,9 +239,11 @@ err_kms_helper_poll_fini:
 err_unbind:
component_unbind_all(dev, drm_dev);
 err_detach_device:
-   arm_iommu_detach_device(dev);
+   if (is_support_iommu)
+   arm_iommu_detach_device(dev);
 err_release_mapping:
-   arm_iommu_release_mapping(mapping);
+   if (is_support_iommu)
+   arm_iommu_release_mapping(mapping);
 err_config_cleanup:
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
@@ -244,7 +258,8 @@ static int rockchip_drm_unload(struct drm_device *drm_dev)
drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
component_unbind_all(dev, drm_dev);
-   arm_iommu_detach_device(dev);
+   if (is_support_iommu)
+   arm_iommu_detach_device(dev);
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;

@@ -488,6 +503,8 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
 * works as expected.
 */
for (i = 0;; i++) {
+   struct device_node *iommu;
+
port = of_parse_phandle(np, "ports", i);
if (!port)
break;
@@ -497,6 +514,17 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
continue;
}

+

[GIT PULL] drm/fsl-dcu: TCON support and fixes for v4.7

On Thu, Apr 28, 2016 at 04:42:28PM -0700, Stefan Agner wrote:
> Hi Dave,
> 
> This adds very rudimentary TCON (timing controller for raw LCD displays)
> support to enable the bypass mode in order to use the DCU controller on
> Freescale/NXP Vybrid SoC's.
> 
> Additionally the register clock and pixel clock has been separated, but
> are currently still enabled and disabled pairwise.
> 
> Other than that, fixes and cleanups accross the driver.

Out of curiosity, does this TCON have anything to do with the one just
posted for rcar-du?
-Daniel

> 
> --
> Stefan
> 
> The following changes since commit 027b3f8ba9277410c3191d72d1ed2c6146d8a668:
> 
>   drm/modes: stop handling framebuffer special (2016-04-22 10:47:16 +1000)
> 
> are available in the git repository at:
> 
>   http://git.agner.ch/git/linux-drm-fsl-dcu.git for-next
> 
> for you to fetch changes up to 0449eefe2db1038a327db45d5428c196f63c0cb9:
> 
>   drm/fsl-dcu: increment version and date (2016-04-25 23:27:08 -0700)
> 
> 
> Arnd Bergmann (1):
>   drm/layerscape: reduce excessive stack usage
> 
> Stefan Agner (11):
>   drm/fsl-dcu: disable clock on initialization failure and remove
>   drm/fsl-dcu: add extra clock for pixel clock
>   drm/fsl-dcu: use common clock framework for pixel clock divider
>   drm/fsl-dcu: add TCON driver
>   drm/fsl-dcu: detach panel on destroy
>   drm/fsl-dcu: handle missing panel gracefully
>   drm/fsl-dcu: use variable name dev for struct drm_device
>   drm/fsl-dcu: deallocate fbdev CMA on unload
>   drm/fsl-dcu: disable output polling on driver unload
>   drm/fsl-dcu: implement lastclose callback
>   drm/fsl-dcu: increment version and date
> 
>  .../devicetree/bindings/display/fsl,dcu.txt|  15 ++-
>  .../devicetree/bindings/display/fsl,tcon.txt   |  18 +++
>  MAINTAINERS|   1 +
>  drivers/gpu/drm/fsl-dcu/Makefile   |   3 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   7 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 127 
> +++--
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  |   2 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  |  38 --
>  drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 111 ++
>  drivers/gpu/drm/fsl-dcu/fsl_tcon.h |  33 ++
>  10 files changed, 298 insertions(+), 57 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/fsl,tcon.txt
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.h
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/4] drm_mode: add TCON encoder/connector

On Fri, Apr 29, 2016 at 12:02:15AM +0300, Sergei Shtylyov wrote:
> TCON (Timing  Controller) usually means  a chip that drives a LCD panel.
> In  our case, such controller  is a part of the Renesas R-Car SoCs. Add
> the TCON encoder/connector #define's  to be used by the TCON support code
> in the Renesas R-Car Display Unit (DU) driver.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  include/uapi/drm/drm_mode.h |2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux/include/uapi/drm/drm_mode.h
> ===
> --- linux.orig/include/uapi/drm/drm_mode.h
> +++ linux/include/uapi/drm/drm_mode.h
> @@ -202,6 +202,7 @@ struct drm_mode_get_plane_res {
>  #define DRM_MODE_ENCODER_VIRTUAL 5
>  #define DRM_MODE_ENCODER_DSI 6
>  #define DRM_MODE_ENCODER_DPMST   7
> +#define DRM_MODE_ENCODER_TCON8
>  
>  struct drm_mode_get_encoder {
>   __u32 encoder_id;
> @@ -241,6 +242,7 @@ struct drm_mode_get_encoder {
>  #define DRM_MODE_CONNECTOR_eDP   14
>  #define DRM_MODE_CONNECTOR_VIRTUAL  15
>  #define DRM_MODE_CONNECTOR_DSI   16
> +#define DRM_MODE_CONNECTOR_TCON  17
>  
>  struct drm_mode_get_connector {

The trouble with adding more here is that everytime you do this all the
userspace needs to be extended to print something reasonable for this type
of connector. For external connectors that makes sense (since users need
to know whether it's the hdmi or DP plug), but for internal panels I'd
honestly just go with lvds for anything that's not a more complex standard
like eDP or DSI.

Just my 2 cents really, not strong opinion, and we'll not run out of
connector type numbers anytime soon ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/etnaviv: remove BUG_ON in MMU unmap path

2016-04-29 Thread Lucas Stach

Am Donnerstag, den 28.04.2016, 15:37 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Apr 28, 2016 at 04:04:58PM +0200, Lucas Stach wrote:
> > The observation was that the common code in iommu_map() rightfully
> > rejected to map things, as mapping something unaligned to the page size
> > is totally bogus.
> 
> Shouldn't iommu_map() detect this?
> 
> /*
>  * both the virtual address and the physical one, as well as
>  * the size of the mapping, must be aligned (at least) to the
>  * size of the smallest page supported by the hardware
>  */
> if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
> pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz 
> 0x%x\n",
>iova, &paddr, size, min_pagesz);
> return -EINVAL;
> }
> 
> where min_pagesz is derived from:
> 
> .pgsize_bitmap = SZ_4K,
> 
> and will be 4096.  So, iommu_map() should reject this, and
> etnaviv_iommu_map() will tear down the partially created mapping, and
> propagate the error code to its caller, that being etnaviv_iommu_map_gem().
> 
> etnaviv_iommu_map_gem() will remove the drm_mm node, propagating the
> failure up to etnaviv_gem_mapping_get(), which will free the
> etnaviv_vram_mapping structure.
> 
> I fail to see how we could get into etnaviv_iommu_unmap() with a bad
> mapping, other than if there's memory corruption, and if there is
> memory corruption, hanging the kernel with a BUG_ON() is totally the
> right thing to do.  Better that than a corrupted filesystem.
> 
Right, if something goes wrong in the unmap() path, something is screwed
with kernel internal state. I'll drop the patch.

Thanks,
Lucas

[Bug 95203] Tonga GST/OMX/VCE encode broken since mesa: st/omx: Fix resource leak on OMX_ErrorNone

https://bugs.freedesktop.org/show_bug.cgi?id=95203

Bug ID: 95203
   Summary: Tonga GST/OMX/VCE encode broken since mesa: st/omx:
Fix resource leak on OMX_ErrorNone
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 123343
  --> https://bugs.freedesktop.org/attachment.cgi?id=123343&action=edit
gst-omx vce failing and working

AMD Tonga since mesa commit -

commit b87856d25d1be1953dea30814994fc40cac5e573
Author: Robert Foss 
Date:   Thu Apr 21 17:49:20 2016 -0400

st/omx: Fix resource leak on OMX_ErrorNone

Avoid leaking buffer allocated for task if an error has occured.

Coverity id: 1213929
Signed-off-by: Robert Foss 
Reviewed-by: Emil Velikov 

I can't encode with gst/omx/vce. It just hangs doing nothing and when I
 c it it throws some errors and quits.

Attached is the output I see from failing followed by working with above commit
reverted.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/f066ae28/attachment.html>

[PULL] topic/drm-misc

Hi Dave,

- prep work for struct_mutex-less gem_free_object
- more invasive/tricky mst fixes from Lyude for broken hw. I discussed
  this with Ville/Jani and we all agreed more soaking in -next would be
  real good this late in the -rc cycle. They're cc: stable too to make
  sure they're not getting lost. Feel free to cherry-pick those four if
  you disagree.
- few small things all over

I'd like to get Noralf's defio work in still for 4.7, but probably with a
separate pull or topic branch.

Cheers, Daniel


The following changes since commit 027b3f8ba9277410c3191d72d1ed2c6146d8a668:

  drm/modes: stop handling framebuffer special (2016-04-22 10:47:16 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-04-29

for you to fetch changes up to be35f94f5c83bfed9ded918162c9b622743ef520:

  drm/atomic: Add missing drm_crtc_internal.h include (2016-04-28 16:36:30 
+0200)


Daniel Vetter (9):
  drm/sysfs: Annote lockless show functions with READ_ONCE
  drm: Give drm_agp_clear drm_legacy_ prefix
  drm: Put legacy lastclose work into drm_legacy_dev_reinit
  drm: Move drm_getmap into drm_bufs.c and give it a legacy prefix
  drm: Push struct_mutex into ->master_destroy
  drm: Forbid legacy MAP functions for DRIVER_MODESET
  drm: Hide master MAP cleanup in drm_bufs.c
  drm: Make drm_vm_open/close_locked private to drm_vm.c
  drm: Protect dev->filelist with its own mutex

Emil Velikov (1):
  MAINTAINERS: Update the files list for the GMA500 DRM driver

Laurent Pinchart (1):
  drm: rcar-du: Fix compilation warning

Lyude (4):
  drm/dp_helper: Always wait before retrying native aux transactions
  drm/dp_helper: Retry aux transactions on all errors
  drm/dp_helper: Perform throw-away read before actual read in 
drm_dp_dpcd_read()
  drm/i915: Get rid of intel_dp_dpcd_read_wake()

Thierry Reding (1):
  drm/atomic: Add missing drm_crtc_internal.h include

Tvrtko Ursulin (2):
  drm: Quiet down drm_mode_getconnector
  drm: Quiet down drm_mode_getresources

Ville SyrjÃ¤lÃ¤ (1):
  drm/dp: Allow signals to interrupt drm_aux-dev reads/writes

 MAINTAINERS |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 ++--
 drivers/gpu/drm/drm_agpsupport.c|  4 +-
 drivers/gpu/drm/drm_atomic.c|  2 +
 drivers/gpu/drm/drm_bufs.c  | 91 +++--
 drivers/gpu/drm/drm_crtc.c  | 12 -
 drivers/gpu/drm/drm_dp_aux_dev.c| 12 +
 drivers/gpu/drm/drm_dp_helper.c | 66 +++-
 drivers/gpu/drm/drm_drv.c   | 11 +---
 drivers/gpu/drm/drm_fops.c  | 51 +-
 drivers/gpu/drm/drm_info.c  |  4 +-
 drivers/gpu/drm/drm_internal.h  |  4 +-
 drivers/gpu/drm/drm_ioctl.c | 54 +--
 drivers/gpu/drm/drm_legacy.h|  2 +
 drivers/gpu/drm/drm_pci.c   |  2 +-
 drivers/gpu/drm/drm_sysfs.c | 11 ++--
 drivers/gpu/drm/drm_vm.c| 16 ++
 drivers/gpu/drm/i915/i915_debugfs.c | 12 -
 drivers/gpu/drm/i915/intel_dp.c | 81 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  1 -
 include/drm/drmP.h  |  1 +
 include/drm/drm_agpsupport.h|  4 +-
 include/drm/drm_legacy.h|  4 +-
 23 files changed, 236 insertions(+), 222 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 95198] Shadow of Mordor beta has missing geometry with gl 4.3

https://bugs.freedesktop.org/show_bug.cgi?id=95198

--- Comment #2 from Ernst Sjï¿½strand  ---
I get very different behavior if I patch Mesa to report 4.3 support vs.
MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430. Is that intended?
There's no environment variable that behaves like if I did such a Mesa patch?

Short story, much fewer issues (or harder to repro?) when patching Mesa to
report 4.3.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160429/4534e92b/attachment-0001.html>

[PATCH v3 0/7] drm: Add fbdev deferred io support to helpers

2016-04-29 Thread Gerd Hoffmann

On Mi, 2016-04-27 at 20:16 +0200, Noralf TrÃ¸nnes wrote:
> I have also added patches that converts qxl and udl to use this
> deferred io support. I have only compile tested it, no functional
> testing.
> I know that qxl is purely a software thing so I could actually test
> it, but
> I have never used qemu so I'm not keen on spending a lot of time on
> that.

Tested-by: Gerd Hoffmann

[PULL] drm-intel-next

Hi Dave,

drm-intel-next-2016-04-25:
- more userptr cornercase fixes from Chris
- clean up and tune forcewake handling (Tvrtko)
- more underrun fixes from Ville, mostly for ilk to appeas CI
- fix unclaimed register warnings on vlv/chv and enable the debug code to catch
  them by default (Ville)
- skl gpu hang fixes for gt3/4 (Mika Kuoppala)
- edram improvements for gen9+ (Mika again)
- clean up gpu reset corner cases (Chris)
- fix ctx/ring machine deaths on snb/ilk (Chris)
- MOCS programming for all engines (Peter Antoine)
- robustify/clean up vlv/chv irq handler (Ville)
- split gen8+ irq handlers into ack/handle phase (Ville)
- tons of bxt rpm fixes (mostly around firmware interactions), from Imre
- hook up panel fitting for dsi panels (Ville)
- more runtime PM fixes all over from Imre
- shrinker polish (Chris)
- more guc fixes from Alex Dai and Dave Gordon
- tons of bugfixes and small polish all over (but with a big focus on bxt)

Final feature pull request for 4.7, after this Jani will take over as
usual with handling the inevitable fallout&fixes ;-)

Cheers, Daniel


The following changes since commit ba3150ac3876acd082307f142597d3482107facc:

  drm/i915: Update DRIVER_DATE to 20160411 (2016-04-11 20:20:18 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-04-25

for you to fetch changes up to 5b4fd5bb1230cd037df3b314e7b36d45d483:

  drm/i915: Update DRIVER_DATE to 20160425 (2016-04-25 09:35:38 +0200)


- more userptr cornercase fixes from Chris
- clean up and tune forcewake handling (Tvrtko)
- more underrun fixes from Ville, mostly for ilk to appeas CI
- fix unclaimed register warnings on vlv/chv and enable the debug code to catch
  them by default (Ville)
- skl gpu hang fixes for gt3/4 (Mika Kuoppala)
- edram improvements for gen9+ (Mika again)
- clean up gpu reset corner cases (Chris)
- fix ctx/ring machine deaths on snb/ilk (Chris)
- MOCS programming for all engines (Peter Antoine)
- robustify/clean up vlv/chv irq handler (Ville)
- split gen8+ irq handlers into ack/handle phase (Ville)
- tons of bxt rpm fixes (mostly around firmware interactions), from Imre
- hook up panel fitting for dsi panels (Ville)
- more runtime PM fixes all over from Imre
- shrinker polish (Chris)
- more guc fixes from Alex Dai and Dave Gordon
- tons of bugfixes and small polish all over (but with a big focus on bxt)


Akash Goel (3):
  drm/i915: Macros to convert PM time interval values to microseconds
  drm/i915: Correct the i915_frequency_info debugfs output
  drm/i915/bxt: Explicitly clear the Turbo control register

Alex Dai (1):
  drm/i915/guc: drop cached copy of 'wq_head'

Chris Wilson (23):
  drm/i915/userptr: Flush cancellations before mmu-notifier invalidate 
returns
  drm/i915/userptr: Hold mmref whilst calling get-user-pages
  drm/i915/userptr: Store i915 backpointer for i915_mm_struct
  drm/i915: Force clean compilation with -Werror
  drm/i915: Disentangle i915_drv.h includes
  drm/i915: Add GEM debugging Kconfig option
  drm/i915: Hide the atomic_read(reset_counter) behind a helper
  drm/i915: Simplify checking of GPU reset_counter in display pageflips
  drm/i915: Tighten reset_counter for reset status
  drm/i915: Store the reset counter when constructing a request
  drm/i915: Simplify reset_counter handling during atomic modesetting
  drm/i915: Prevent leaking of -EIO from i915_wait_request()
  drm/i915: Suppress error message when GPU resets are disabled
  drm/i915: Prevent machine death on Ivybridge context switching
  drm/i915: Force ringbuffers to not be at offset 0
  drm/i915: Move the mb() following release-mmap into release-mmap
  drm/i915: Split out !RCS legacy context switching
  drm/i915: Reorganise legacy context switch to cope with late failure
  drm/i915: Late request cancellations are harmful
  drm/i915: Avoid stalling on pending flips for legacy cursor updates
  drm/i915/shrinker: Only report objects with extra pinned pages as pinned
  drm/i915/shrinker: Report "unevictable" pages
  drm/i915/shrinker: Only shmemfs objects are backed by swap

Daniel Vetter (1):
  drm/i915: Update DRIVER_DATE to 20160425

Dave Gordon (3):
  drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel
  drm/i915/guc: local optimisations and updating comments
  drm/i915: check for ERR_PTR from i915_gem_object_pin_map()

Dongwon Kim (1):
  drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations

Gustavo Padovan (1):
  drm/i915: use drm_crtc_send_vblank_event()

Imre Deak (29):
  drm/i915/bxt: Reject DMC firmware versions with known bugs
  drm/i915/bxt: Fix GRC code register field definitions
  drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-on

[RFC v2 5/8] drm/fence: add in-fences support

2016-04-29 Thread Daniel Stone

Hi,

On 28 April 2016 at 23:28, Rob Clark  wrote:
> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter  wrote:
>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
>>> A (per-CRTC?) array of fences would be more flexible.  And even in the cases
>>> where you could make a 1-to-1 mapping between planes and fences, it's not
>>> that much more work for userspace to assemble those fences into an array
>>> anyway.
>>
>> I'm ok with an array too if that's what you folks prefer (it's meant to be
>> used by you after all). I just don't want just 1 fence for the entire op,
>> forcing userspace to first merge them all together. That seems silly.
>
> I was kinda more a fan of array too, if for no other reason that to be
> consistent w/ how out-fences work.  (And using property just for
> in-fence seemed slightly weird/abusive to me)

I don't think it's really useful to look for much consistency between
the two, beyond the name. I'm more concerned with consistency between
in-fences and the implicit fences on buffers/FBs, and between
out-fences and the page_flip_events.

>> One side-effect of that is that we'd also have to rework all the internal
>> bits and move fences around in atomic. Which means change a pile of
>> drivers. Not sure that's worth it, but I'd be ok either way really.
>
> hmm, well we could keep the array per-plane (and if one layer is using
> multiple planes, just list the same fd multiple times).. then it
> mostly comes down to changes in the ioctl fxn itself.

... and new API in libdrm, which is going to be a serious #ifdef and
distribution pain. The core property API has been available since
2.4.62 last June, but for this we'd have to write the code, wait for
the kernel code, wait for HWC, get everything together, and then merge
and release. That gives minimum one year of libdrm releases which have
had atomic but not in-fence API support, if we're adding a new array.
And I just don't really see what it buys us, apart from the need for
the core atomic_get_property helper to statically return -1 when
requesting FENCE_FD.

Cheers,
Daniel

[PATCH v3 2/2] dt-bindings: imx: ldb: Add ddc-i2c-bus property

2016-04-29 Thread Philipp Zabel

Am Donnerstag, den 28.04.2016, 16:48 -0500 schrieb Rob Herring:
> On Wed, Apr 27, 2016 at 04:23:34PM -0400, Akshay Bhat wrote:
> > Document the ddc-i2c-bus property used by imx-ldb driver to read EDID
> > information via I2C interface.
> > 
> > Signed-off-by: Akshay Bhat 
> > ---
> > 
> > v3:
> > Newly added.
> > 
> >  Documentation/devicetree/bindings/display/imx/ldb.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt 
> > b/Documentation/devicetree/bindings/display/imx/ldb.txt
> > index 0a175d9..a407462 100644
> > --- a/Documentation/devicetree/bindings/display/imx/ldb.txt
> > +++ b/Documentation/devicetree/bindings/display/imx/ldb.txt
> > @@ -62,6 +62,7 @@ Required properties:
> > display-timings are used instead.
> >  
> >  Optional properties (required if display-timings are used):
> 
> The required part doesn't make sense if you add this, but...
> 
> > + - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> 
> Really, this should be part of a connector node since i2c goes from the 
> i2c controller to a connector and is not part of the display controller.

If the ddc i2c bus does indeed go through a connector, yes. Would that
warrant a generic "lvds-connector" binding for all those different types
of internal LVDS connectors?

regards
Philipp

[PATCH] drm/omap: check plane size