[PATCH libdrm v2 8/8] drm: use correct printf modifiers

2015-03-26 Thread Emil Velikov
The valies are unsigned long, thus we should use %lu.

v2: Drop old printf statement. (Jan)

Signed-off-by: Emil Velikov 
---
 xf86drmHash.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xf86drmHash.c b/xf86drmHash.c
index 199a2a3..f287e61 100644
--- a/xf86drmHash.c
+++ b/xf86drmHash.c
@@ -99,7 +99,7 @@ static unsigned long HashHash(unsigned long key)

 hash %= HASH_SIZE;
 #if DEBUG
-printf( "Hash(%d) = %d\n", key, hash);
+printf( "Hash(%lu) = %lu\n", key, hash);
 #endif
 return hash;
 }
@@ -202,7 +202,7 @@ int drmHashInsert(void *t, unsigned long key, void *value)
 bucket->next = table->buckets[hash];
 table->buckets[hash] = bucket;
 #if DEBUG
-printf("Inserted %d at %d/%p\n", key, hash, bucket);
+printf("Inserted %lu at %lu/%p\n", key, hash, bucket);
 #endif
 return 0;  /* Added to table */
 }
-- 
2.3.1



[PATCH libdrm v2 7/8] drm: replace HASH_DEBUG with DEBUG

2015-03-26 Thread Emil Velikov
... and remove the useless SL_DEBUG and RANDOM_DEBUG

v2: Rebase on earlier changes.

Signed-off-by: Emil Velikov 
---
 xf86drmHash.c   | 5 ++---
 xf86drmRandom.c | 1 -
 xf86drmSL.c | 1 -
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/xf86drmHash.c b/xf86drmHash.c
index f7d7f73..199a2a3 100644
--- a/xf86drmHash.c
+++ b/xf86drmHash.c
@@ -75,7 +75,6 @@
 #include "xf86drmHash.h"

 #define HASH_MAGIC 0xdeadbeef
-#define HASH_DEBUG 0

 static unsigned long HashHash(unsigned long key)
 {
@@ -99,7 +98,7 @@ static unsigned long HashHash(unsigned long key)
 }

 hash %= HASH_SIZE;
-#if HASH_DEBUG
+#if DEBUG
 printf( "Hash(%d) = %d\n", key, hash);
 #endif
 return hash;
@@ -202,7 +201,7 @@ int drmHashInsert(void *t, unsigned long key, void *value)
 bucket->value= value;
 bucket->next = table->buckets[hash];
 table->buckets[hash] = bucket;
-#if HASH_DEBUG
+#if DEBUG
 printf("Inserted %d at %d/%p\n", key, hash, bucket);
 #endif
 return 0;  /* Added to table */
diff --git a/xf86drmRandom.c b/xf86drmRandom.c
index b3a4be9..81f0301 100644
--- a/xf86drmRandom.c
+++ b/xf86drmRandom.c
@@ -78,7 +78,6 @@
 #include "xf86drmRandom.h"

 #define RANDOM_MAGIC 0xfeedbeef
-#define RANDOM_DEBUG 0

 void *drmRandomCreate(unsigned long seed)
 {
diff --git a/xf86drmSL.c b/xf86drmSL.c
index acddb54..9bbf8fb 100644
--- a/xf86drmSL.c
+++ b/xf86drmSL.c
@@ -53,7 +53,6 @@
 #define SL_ENTRY_MAGIC 0x00fab1edLU
 #define SL_FREED_MAGIC 0xdecea5edLU
 #define SL_MAX_LEVEL   16
-#define SL_DEBUG   0
 #define SL_RANDOM_SEED 0xc01055a1LU

 #if SL_MAIN
-- 
2.3.1



[PATCH libdrm v2 6/8] tests/random: return non-zero on test failure

2015-03-26 Thread Emil Velikov
... and wire it up to make check

v2: s/rand - state->check/rand != state->check/. (Jan)

Signed-off-by: Emil Velikov 
---
 tests/Makefile.am | 6 +++---
 tests/random.c| 6 --
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index e3443df..d129317 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -29,15 +29,15 @@ LDADD = $(top_builddir)/libdrm.la

 check_PROGRAMS = \
dristat \
-   drmstat \
-   random
+   drmstat

 if HAVE_NOUVEAU
 SUBDIRS += nouveau
 endif

 TESTS = \
-   hash
+   hash \
+   random

 if HAVE_LIBUDEV

diff --git a/tests/random.c b/tests/random.c
index db341f9..13d4c80 100644
--- a/tests/random.c
+++ b/tests/random.c
@@ -98,15 +98,17 @@ int main(void)
 {
 RandomState   *state;
 int   i;
+int   ret;
 unsigned long rand;

 state = drmRandomCreate(1);
 for (i = 0; i < 1; i++) {
rand = drmRandom(state);
 }
+ret = rand != state->check;
 printf("After 1 iterations: %lu (%lu expected): %s\n",
   rand, state->check,
-  rand - state->check ? "*INCORRECT*" : "CORRECT");
+  ret ? "*INCORRECT*" : "CORRECT");
 drmRandomDestroy(state);

 printf("Checking periods...\n");
@@ -114,5 +116,5 @@ int main(void)
 check_period(2);
 check_period(31415926);

-return 0;
+return ret;
 }
-- 
2.3.1



[PATCH libdrm v2 5/8] tests/random: extract test out of xf86drmRandom.c

2015-03-26 Thread Emil Velikov
With follow up commits we can clear it up and wire to
make check

v2:
 - Use xf86drmRandom.h for common struct.(Jan)
 - Add test to .gitignore.

Signed-off-by: Emil Velikov 
---
 .gitignore|   1 +
 Makefile.sources  |   1 +
 tests/Makefile.am |   3 +-
 tests/random.c| 118 ++
 xf86drmRandom.c   |  78 ++--
 xf86drmRandom.h   |  35 
 6 files changed, 161 insertions(+), 75 deletions(-)
 create mode 100644 tests/random.c
 create mode 100644 xf86drmRandom.h

diff --git a/.gitignore b/.gitignore
index 0faa825..cc31f8f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -81,6 +81,7 @@ tests/getversion
 tests/hash
 tests/lock
 tests/openclose
+tests/random
 tests/setversion
 tests/updatedraw
 tests/modeprint/modeprint
diff --git a/Makefile.sources b/Makefile.sources
index ff4fe5e..f215747 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -3,6 +3,7 @@ LIBDRM_FILES := \
xf86drmHash.c \
xf86drmHash.h \
xf86drmRandom.c \
+   xf86drmRandom.h \
xf86drmSL.c \
xf86drmMode.c \
xf86atomic.h \
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 79a13c4..e3443df 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -29,7 +29,8 @@ LDADD = $(top_builddir)/libdrm.la

 check_PROGRAMS = \
dristat \
-   drmstat
+   drmstat \
+   random

 if HAVE_NOUVEAU
 SUBDIRS += nouveau
diff --git a/tests/random.c b/tests/random.c
new file mode 100644
index 000..db341f9
--- /dev/null
+++ b/tests/random.c
@@ -0,0 +1,118 @@
+/* xf86drmRandom.c -- "Minimal Standard" PRNG Implementation
+ * Created: Mon Apr 19 08:28:13 1999 by faith at precisioninsight.com
+ *
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * All Rights Reserved.
+ *
+ * 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
+ * PRECISION INSIGHT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ * 
+ * Authors: Rickard E. (Rik) Faith 
+ *
+ * DESCRIPTION
+ *
+ * This file contains a simple, straightforward implementation of the Park
+ * & Miller "Minimal Standard" PRNG [PM88, PMS93], which is a Lehmer
+ * multiplicative linear congruential generator (MLCG) with a period of
+ * 2^31-1.
+ *
+ * This implementation is intended to provide a reliable, portable PRNG
+ * that is suitable for testing a hash table implementation and for
+ * implementing skip lists.
+ *
+ * FUTURE ENHANCEMENTS
+ *
+ * If initial seeds are not selected randomly, two instances of the PRNG
+ * can be correlated.  [Knuth81, pp. 32-33] describes a shuffling technique
+ * that can eliminate this problem.
+ *
+ * If PRNGs are used for simulation, the period of the current
+ * implementation may be too short.  [LE88] discusses methods of combining
+ * MLCGs to produce much longer periods, and suggests some alternative
+ * values for A and M.  [LE90 and Sch92] also provide information on
+ * long-period PRNGs.
+ *
+ * REFERENCES
+ *
+ * [Knuth81] Donald E. Knuth. The Art of Computer Programming.  Volume 2:
+ * Seminumerical Algorithms.  Reading, Massachusetts: Addison-Wesley, 1981.
+ *
+ * [LE88] Pierre L'Ecuyer. "Efficient and Portable Combined Random Number
+ * Generators".  CACM 31(6), June 1988, pp. 742-774.
+ *
+ * [LE90] Pierre L'Ecuyer. "Random Numbers for Simulation". CACM 33(10,
+ * October 1990, pp. 85-97.
+ *
+ * [PM88] Stephen K. Park and Keith W. Miller. "Random Number Generators:
+ * Good Ones are Hard to Find". CACM 31(10), October 1988, pp. 1192-1201.
+ *
+ * [Sch92] Bruce Schneier. "Pseudo-Ransom Sequence Generator for 32-Bit
+ * CPUs".  Dr. Dobb's Journal 17(2), February 1992, pp. 34, 37-38, 40.
+ *
+ * [PMS93] Stephen K. Park, Keith W. Miller, and Paul K. Stockmeyer.  In
+ * "Technical Correspondence: Remarks on Choosing and Implementing Random
+ * Number Generators". CACM 36(7), July 1993, pp. 105-110.
+ *
+ */
+
+#include 
+#include 
+
+#include "xf86drm.h"
+#include "xf86drmRandom.h"
+
+static void check_

[PATCH libdrm v2 4/8] tests/hash: return non-zero on failure

2015-03-26 Thread Emil Velikov
... and wire up to `make check' now that it's useful.

v2: Really return non-zero on failure.

Signed-off-by: Emil Velikov 
---
 tests/Makefile.am | 10 ++
 tests/hash.c  | 26 +++---
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index ea826b5..79a13c4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -29,13 +29,15 @@ LDADD = $(top_builddir)/libdrm.la

 check_PROGRAMS = \
dristat \
-   drmstat \
-   hash
+   drmstat

 if HAVE_NOUVEAU
 SUBDIRS += nouveau
 endif

+TESTS = \
+   hash
+
 if HAVE_LIBUDEV

 check_LTLIBRARIES = libdrmtest.la
@@ -62,6 +64,6 @@ TESTS =   \
updatedraw  \
name_from_fd

-check_PROGRAMS += $(TESTS)
-
 endif
+
+check_PROGRAMS += $(TESTS)
diff --git a/tests/hash.c b/tests/hash.c
index 1543c86..fc093c1 100644
--- a/tests/hash.c
+++ b/tests/hash.c
@@ -121,8 +121,8 @@ static void compute_dist(HashTablePtr table)
 }
 }

-static void check_table(HashTablePtr table,
-unsigned long key, void * value)
+static int check_table(HashTablePtr table,
+   unsigned long key, void * value)
 {
 void *retval;
 int   retcode = drmHashLookup(table, key, &retval);
@@ -138,28 +138,32 @@ static void check_table(HashTablePtr table,
key, value, retval);
 break;
 case 0:
-if (value != retval)
+if (value != retval) {
 printf("Bad value: key = %lu, expected = %p, returned = %p\n",
key, value, retval);
+retcode = -1;
+}
 break;
 default:
 printf("Bad retcode = %d: key = %lu, expected = %p, returned = %p\n",
retcode, key, value, retval);
 break;
 }
+return retcode;
 }

 int main(void)
 {
 HashTablePtr  table;
 unsigned long i;
+int   ret;

 printf("\n* 256 consecutive integers \n");
 table = drmHashCreate();
 for (i = 0; i < 256; i++)
 drmHashInsert(table, i, (void *)(i << 16 | i));
 for (i = 0; i < 256; i++)
-check_table(table, i, (void *)(i << 16 | i));
+ret |= check_table(table, i, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

@@ -168,7 +172,7 @@ int main(void)
 for (i = 0; i < 1024; i++)
 drmHashInsert(table, i, (void *)(i << 16 | i));
 for (i = 0; i < 1024; i++)
-check_table(table, i, (void *)(i << 16 | i));
+ret |= check_table(table, i, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

@@ -177,7 +181,7 @@ int main(void)
 for (i = 0; i < 1024; i++)
 drmHashInsert(table, i*4096, (void *)(i << 16 | i));
 for (i = 0; i < 1024; i++)
-check_table(table, i*4096, (void *)(i << 16 | i));
+ret |= check_table(table, i*4096, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

@@ -188,10 +192,10 @@ int main(void)
 drmHashInsert(table, random(), (void *)(i << 16 | i));
 srandom(0xbeefbeef);
 for (i = 0; i < 1024; i++)
-check_table(table, random(), (void *)(i << 16 | i));
+ret |= check_table(table, random(), (void *)(i << 16 | i));
 srandom(0xbeefbeef);
 for (i = 0; i < 1024; i++)
-check_table(table, random(), (void *)(i << 16 | i));
+ret |= check_table(table, random(), (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

@@ -202,12 +206,12 @@ int main(void)
 drmHashInsert(table, random(), (void *)(i << 16 | i));
 srandom(0xbeefbeef);
 for (i = 0; i < 5000; i++)
-check_table(table, random(), (void *)(i << 16 | i));
+ret |= check_table(table, random(), (void *)(i << 16 | i));
 srandom(0xbeefbeef);
 for (i = 0; i < 5000; i++)
-check_table(table, random(), (void *)(i << 16 | i));
+ret |= check_table(table, random(), (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

-return 0;
+return ret;
 }
-- 
2.3.1



[PATCH libdrm v2 3/8] tests/hash: style fixes

2015-03-26 Thread Emil Velikov
v2: Rebase on earlier changes. Keep count initialisation as is.

Signed-off-by: Emil Velikov 
Reviewed-by: Jan Vesely 
---
 tests/hash.c | 90 
 1 file changed, 54 insertions(+), 36 deletions(-)

diff --git a/tests/hash.c b/tests/hash.c
index ee11e23..1543c86 100644
--- a/tests/hash.c
+++ b/tests/hash.c
@@ -80,21 +80,25 @@ static int dist[DIST_LIMIT];
 static void clear_dist(void) {
 int i;

-for (i = 0; i < DIST_LIMIT; i++) dist[i] = 0;
+for (i = 0; i < DIST_LIMIT; i++)
+dist[i] = 0;
 }

 static int count_entries(HashBucketPtr bucket)
 {
 int count = 0;

-for (; bucket; bucket = bucket->next) ++count;
+for (; bucket; bucket = bucket->next)
+++count;
 return count;
 }

 static void update_dist(int count)
 {
-if (count >= DIST_LIMIT) ++dist[DIST_LIMIT-1];
-else ++dist[count];
+if (count >= DIST_LIMIT)
+++dist[DIST_LIMIT-1];
+else
+++dist[count];
 }

 static void compute_dist(HashTablePtr table)
@@ -103,43 +107,45 @@ static void compute_dist(HashTablePtr table)
 HashBucketPtr bucket;

 printf("Entries = %ld, hits = %ld, partials = %ld, misses = %ld\n",
-  table->entries, table->hits, table->partials, table->misses);
+  table->entries, table->hits, table->partials, table->misses);
 clear_dist();
 for (i = 0; i < HASH_SIZE; i++) {
-   bucket = table->buckets[i];
-   update_dist(count_entries(bucket));
+bucket = table->buckets[i];
+update_dist(count_entries(bucket));
 }
 for (i = 0; i < DIST_LIMIT; i++) {
-   if (i != DIST_LIMIT-1) printf("%5d %10d\n", i, dist[i]);
-   else   printf("other %10d\n", dist[i]);
+if (i != DIST_LIMIT-1)
+printf("%5d %10d\n", i, dist[i]);
+else
+printf("other %10d\n", dist[i]);
 }
 }

 static void check_table(HashTablePtr table,
-   unsigned long key, void * value)
+unsigned long key, void * value)
 {
 void *retval;
 int   retcode = drmHashLookup(table, key, &retval);

 switch (retcode) {
 case -1:
-   printf("Bad magic = 0x%08lx:"
-  " key = %lu, expected = %p, returned = %p\n",
-  table->magic, key, value, retval);
-   break;
+printf("Bad magic = 0x%08lx:"
+   " key = %lu, expected = %p, returned = %p\n",
+   table->magic, key, value, retval);
+break;
 case 1:
-   printf("Not found: key = %lu, expected = %p, returned = %p\n",
-  key, value, retval);
-   break;
+printf("Not found: key = %lu, expected = %p, returned = %p\n",
+   key, value, retval);
+break;
 case 0:
-   if (value != retval)
-   printf("Bad value: key = %lu, expected = %p, returned = %p\n",
-  key, value, retval);
-   break;
+if (value != retval)
+printf("Bad value: key = %lu, expected = %p, returned = %p\n",
+   key, value, retval);
+break;
 default:
-   printf("Bad retcode = %d: key = %lu, expected = %p, returned = %p\n",
-  retcode, key, value, retval);
-   break;
+printf("Bad retcode = %d: key = %lu, expected = %p, returned = %p\n",
+   retcode, key, value, retval);
+break;
 }
 }

@@ -150,44 +156,56 @@ int main(void)

 printf("\n* 256 consecutive integers \n");
 table = drmHashCreate();
-for (i = 0; i < 256; i++) drmHashInsert(table, i, (void *)(i << 16 | i));
-for (i = 0; i < 256; i++) check_table(table, i, (void *)(i << 16 | i));
+for (i = 0; i < 256; i++)
+drmHashInsert(table, i, (void *)(i << 16 | i));
+for (i = 0; i < 256; i++)
+check_table(table, i, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 1024 consecutive integers \n");
 table = drmHashCreate();
-for (i = 0; i < 1024; i++) drmHashInsert(table, i, (void *)(i << 16 | i));
-for (i = 0; i < 1024; i++) check_table(table, i, (void *)(i << 16 | i));
+for (i = 0; i < 1024; i++)
+drmHashInsert(table, i, (void *)(i << 16 | i));
+for (i = 0; i < 1024; i++)
+check_table(table, i, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 1024 consecutive page addresses (4k pages) \n");
 table = drmHashCreate();
-for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, (void *)(i << 16 | 
i));
-for (i = 0; i < 1024; i++) check_table(table, i*4096, (void *)(i << 16 | 
i));
+for (i = 0; i < 1024; i++)
+drmHashInsert(table, i*4096, (void *)(i << 16 | i));
+for (i = 0; i < 1024; i++)
+check_table(table, i*4096, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 1024 random integers \n");
 table = drm

[PATCH libdrm v2 2/8] tests/hash: misc compilation fixes

2015-03-26 Thread Emil Velikov
Get the test from completely broken to working like a charm.

 - Use the same variable type for both HashInsert and HashLookup.
 - Use correct storage type for the HashLookup return value.
 - Remove useless backward iteration of HashLookup(i).

v2:
 - Use void * instead of unsigned long.
 - Change value to key << 16 | key.

Signed-off-by: Emil Velikov 
---
 tests/hash.c | 45 +
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/tests/hash.c b/tests/hash.c
index 517a667..ee11e23 100644
--- a/tests/hash.c
+++ b/tests/hash.c
@@ -116,28 +116,28 @@ static void compute_dist(HashTablePtr table)
 }

 static void check_table(HashTablePtr table,
-   unsigned long key, unsigned long value)
+   unsigned long key, void * value)
 {
-unsigned long retval  = 0;
-int   retcode = drmHashLookup(table, key, &retval);
+void *retval;
+int   retcode = drmHashLookup(table, key, &retval);

 switch (retcode) {
 case -1:
printf("Bad magic = 0x%08lx:"
-  " key = %lu, expected = %lu, returned = %lu\n",
+  " key = %lu, expected = %p, returned = %p\n",
   table->magic, key, value, retval);
break;
 case 1:
-   printf("Not found: key = %lu, expected = %lu returned = %lu\n",
+   printf("Not found: key = %lu, expected = %p, returned = %p\n",
   key, value, retval);
break;
 case 0:
if (value != retval)
-   printf("Bad value: key = %lu, expected = %lu, returned = %lu\n",
+   printf("Bad value: key = %lu, expected = %p, returned = %p\n",
   key, value, retval);
break;
 default:
-   printf("Bad retcode = %d: key = %lu, expected = %lu, returned = %lu\n",
+   printf("Bad retcode = %d: key = %lu, expected = %p, returned = %p\n",
   retcode, key, value, retval);
break;
 }
@@ -145,52 +145,49 @@ static void check_table(HashTablePtr table,

 int main(void)
 {
-HashTablePtr table;
-int  i;
+HashTablePtr  table;
+unsigned long i;

 printf("\n* 256 consecutive integers \n");
 table = drmHashCreate();
-for (i = 0; i < 256; i++) drmHashInsert(table, i, i);
-for (i = 0; i < 256; i++) check_table(table, i, i);
-for (i = 256; i >= 0; i--) check_table(table, i, i);
+for (i = 0; i < 256; i++) drmHashInsert(table, i, (void *)(i << 16 | i));
+for (i = 0; i < 256; i++) check_table(table, i, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 1024 consecutive integers \n");
 table = drmHashCreate();
-for (i = 0; i < 1024; i++) drmHashInsert(table, i, i);
-for (i = 0; i < 1024; i++) check_table(table, i, i);
-for (i = 1024; i >= 0; i--) check_table(table, i, i);
+for (i = 0; i < 1024; i++) drmHashInsert(table, i, (void *)(i << 16 | i));
+for (i = 0; i < 1024; i++) check_table(table, i, (void *)(i << 16 | i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 1024 consecutive page addresses (4k pages) \n");
 table = drmHashCreate();
-for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, i);
-for (i = 0; i < 1024; i++) check_table(table, i*4096, i);
-for (i = 1024; i >= 0; i--) check_table(table, i*4096, i);
+for (i = 0; i < 1024; i++) drmHashInsert(table, i*4096, (void *)(i << 16 | 
i));
+for (i = 0; i < 1024; i++) check_table(table, i*4096, (void *)(i << 16 | 
i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 1024 random integers \n");
 table = drmHashCreate();
 srandom(0xbeefbeef);
-for (i = 0; i < 1024; i++) drmHashInsert(table, random(), i);
+for (i = 0; i < 1024; i++) drmHashInsert(table, random(), (void *)(i << 16 
| i));
 srandom(0xbeefbeef);
-for (i = 0; i < 1024; i++) check_table(table, random(), i);
+for (i = 0; i < 1024; i++) check_table(table, random(), (void *)(i << 16 | 
i));
 srandom(0xbeefbeef);
-for (i = 0; i < 1024; i++) check_table(table, random(), i);
+for (i = 0; i < 1024; i++) check_table(table, random(), (void *)(i << 16 | 
i));
 compute_dist(table);
 drmHashDestroy(table);

 printf("\n* 5000 random integers \n");
 table = drmHashCreate();
 srandom(0xbeefbeef);
-for (i = 0; i < 5000; i++) drmHashInsert(table, random(), i);
+for (i = 0; i < 5000; i++) drmHashInsert(table, random(), (void *)(i << 16 
| i));
 srandom(0xbeefbeef);
-for (i = 0; i < 5000; i++) check_table(table, random(), i);
+for (i = 0; i < 5000; i++) check_table(table, random(), (void *)(i << 16 | 
i));
 srandom(0xbeefbeef);
-for (i = 0; i < 5000; i++) check_table(table, random(), i);
+for (i = 0; i < 5000; i++) check_table(table, random(), (void *)(i << 16 | 
i));
 compute_dist(table);
 drmHashDestroy(table);

-- 
2.3.1



[PATCH libdrm v2 1/8] tests/hash: extract test out of xf86drmHash.c

2015-03-26 Thread Emil Velikov
This way with follow up commits we can fix it and wire it up to
make check

v2:
 - Use xf86drmHash.h for common structs.(Jan)
 - Add test to .gitignore.

Signed-off-by: Emil Velikov 
---
 .gitignore|   1 +
 Makefile.sources  |   1 +
 tests/Makefile.am |   3 +-
 tests/hash.c  | 198 ++
 xf86drmHash.c | 196 +++--
 xf86drmHash.h |  47 +
 6 files changed, 260 insertions(+), 186 deletions(-)
 create mode 100644 tests/hash.c
 create mode 100644 xf86drmHash.h

diff --git a/.gitignore b/.gitignore
index 06cc928..0faa825 100644
--- a/.gitignore
+++ b/.gitignore
@@ -78,6 +78,7 @@ tests/drmstat
 tests/getclient
 tests/getstats
 tests/getversion
+tests/hash
 tests/lock
 tests/openclose
 tests/setversion
diff --git a/Makefile.sources b/Makefile.sources
index 566f7b5..ff4fe5e 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -1,6 +1,7 @@
 LIBDRM_FILES := \
xf86drm.c \
xf86drmHash.c \
+   xf86drmHash.h \
xf86drmRandom.c \
xf86drmSL.c \
xf86drmMode.c \
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 10f54e3..ea826b5 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -29,7 +29,8 @@ LDADD = $(top_builddir)/libdrm.la

 check_PROGRAMS = \
dristat \
-   drmstat
+   drmstat \
+   hash

 if HAVE_NOUVEAU
 SUBDIRS += nouveau
diff --git a/tests/hash.c b/tests/hash.c
new file mode 100644
index 000..517a667
--- /dev/null
+++ b/tests/hash.c
@@ -0,0 +1,198 @@
+/* xf86drmHash.c -- Small hash table support for integer -> integer mapping
+ * Created: Sun Apr 18 09:35:45 1999 by faith at precisioninsight.com
+ *
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * All Rights Reserved.
+ *
+ * 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
+ * PRECISION INSIGHT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Rickard E. (Rik) Faith 
+ *
+ * DESCRIPTION
+ *
+ * This file contains a straightforward implementation of a fixed-sized
+ * hash table using self-organizing linked lists [Knuth73, pp. 398-399] for
+ * collision resolution.  There are two potentially interesting things
+ * about this implementation:
+ *
+ * 1) The table is power-of-two sized.  Prime sized tables are more
+ * traditional, but do not have a significant advantage over power-of-two
+ * sized table, especially when double hashing is not used for collision
+ * resolution.
+ *
+ * 2) The hash computation uses a table of random integers [Hanson97,
+ * pp. 39-41].
+ *
+ * FUTURE ENHANCEMENTS
+ *
+ * With a table size of 512, the current implementation is sufficient for a
+ * few hundred keys.  Since this is well above the expected size of the
+ * tables for which this implementation was designed, the implementation of
+ * dynamic hash tables was postponed until the need arises.  A common (and
+ * naive) approach to dynamic hash table implementation simply creates a
+ * new hash table when necessary, rehashes all the data into the new table,
+ * and destroys the old table.  The approach in [Larson88] is superior in
+ * two ways: 1) only a portion of the table is expanded when needed,
+ * distributing the expansion cost over several insertions, and 2) portions
+ * of the table can be locked, enabling a scalable thread-safe
+ * implementation.
+ *
+ * REFERENCES
+ *
+ * [Hanson97] David R. Hanson.  C Interfaces and Implementations:
+ * Techniques for Creating Reusable Software.  Reading, Massachusetts:
+ * Addison-Wesley, 1997.
+ *
+ * [Knuth73] Donald E. Knuth. The Art of Computer Programming.  Volume 3:
+ * Sorting and Searching.  Reading, Massachusetts: Addison-Wesley, 1973.
+ *
+ * [Larson88] Per-Ake Larson. "Dynamic Hash Tables".  CACM 31(4), April
+ * 1988, pp. 446-457.
+ *
+ */
+
+#include 
+#include 
+
+#include "xf86drm.h"
+#include "xf86drmHash.h"
+
+#define DIST_LIMIT 10
+static int dist[DIST_LIMIT];
+
+static void clear_dist(void) {

[PATCH] xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic

2015-03-26 Thread Daniel Kurtz
Hi Emil,

On Thu, Mar 26, 2015 at 11:12 PM, Emil Velikov  
wrote:
>
> Hi Daniel,
> On 25/03/15 01:01, Daniel Kurtz wrote:
> > Unfortunately, there are some users of libdrm installed headers that like
> > to be built with -std=c89 -pedantic, which does not like "inline".
> >
> > However, __inline works.
> >
> > Signed-off-by: Daniel Kurtz 
>
> > ---
> >  xf86drmMode.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xf86drmMode.h b/xf86drmMode.h
> > index 856a6bb..2d30184 100644
> > --- a/xf86drmMode.h
> > +++ b/xf86drmMode.h
> > @@ -240,7 +240,7 @@ typedef struct _drmModeProperty {
> >   uint32_t *blob_ids; /* store the blob IDs */
> >  } drmModePropertyRes, *drmModePropertyPtr;
> >
> > -static inline int drm_property_type_is(drmModePropertyPtr property,
> > +static __inline int drm_property_type_is(drmModePropertyPtr property,
>
> Can you share the name of those users ?
>
> From a quick look clang and gcc are ok with this change, although some
> versions of the Sun compiler are not. Considering that most programs try
> to use c99 and later, might I suggest that you add a trivial wrapper in
> your program ? Something along the lines of
>
> #ifndef inline
> #define inline __inline
> #endif

It isn't a program, its a third party EGL/GLES driver, so, no I can't
really do this easily.

Alternatively can we:
 (1) move the wrapper to xf86drmMode.h itself, or
 (2) move this inline helper function out of xf86drmMode.h and into
the two libdrm tests that use it (or a shared test helper .h [0])
 (3) remove the inline and make drm_property_type_is a non-inline
function in xf86drmMode.c

[0] I think Thierry already has a patch set that rearranges the tests
to use some shared headers.  Perhaps this will work well once his set
lands.

-Dan

>
>
> -Emil
>


[PATCH] drm: Exynos: Respect framebuffer pitch for FIMD/Mixer

2015-03-26 Thread Inki Dae
Hello Javier,

Applied.

Could you use right prefix of the subject like below when you post patch?

'drm/exynos: ...', not 'drm: Exynos: ...'

Your email will be filtered from my mailbox if you don't use the right
prefix so I couldn't check and take care of your patch.

Thanks,
Inki Dae

On 2015년 03월 24일 17:57, Javier Martinez Canillas wrote:
> Hello Inki,
> 
> On Tue, Mar 17, 2015 at 2:24 PM, Daniel Stone  
> wrote:
>> When performing a modeset, use the framebuffer pitch value to set FIMD
>> IMG_SIZE and Mixer SPAN registers. These are both defined as pitch - the
>> distance between contiguous lines (bytes for FIMD, pixels for mixer).
>>
>> Fixes display on Snow (1366x768).
>>
>> Signed-off-by: Daniel Stone 
>> Tested-by: Javier Martinez Canillas 
> 
> Any comments on this patch? It would be great to pick this sooner
> rather than later since it fixes (at least) display output on Snow and
> HDMI output on Peach Pit/Pi.
> 
> Best regards,
> Javier
> 



[Bug 89784] Complex shader compilation fails (spilling related?)

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89784

Bug ID: 89784
   Summary: Complex shader compilation fails (spilling related?)
   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: greg at chown.ath.cx
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 114655
  --> https://bugs.freedesktop.org/attachment.cgi?id=114655&action=edit
LLVM assembly of shader

The attached shader (LLVM assembly, dumped with R600_DEBUG=ps) fails to compile
with latest LLVM trunk. AFAIR it worked at some point with some combination of
Mesa and LLVM, but I couldn't reproduce this.

Compile with
> llc -march=amdgcn -mcpu=SI -mattr=+vgpr-spilling -verify-machineinstrs < 
> bug.ll

to reproduce. It looks like it is spilling related.

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


[PATCH] drm/atomic-helpers: Properly avoid full modeset dance

2015-03-26 Thread Daniel Vetter
Legacy setCrtc has a nice fastpath for just updating the frontbuffer
when the output routing doesn't change. Which I of course tried to
keep working, except that I fumbled the job: The helpers correctly
compute ->mode_changed, CRTC updates get correctly skipped but
connector functions are called unconditionally.

Fix this.

Reported-and-Tested-by: Gustavo Padovan 
Reviewed-by: Gustavo Padovan 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d9ed9a54fd1e..6e377d954538 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -587,7 +587,8 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)

old_crtc_state = 
old_state->crtc_states[drm_crtc_index(old_conn_state->crtc)];

-   if (!old_crtc_state->active)
+   if (!old_crtc_state->active ||
+   !needs_modeset(connector->state->crtc->state))
continue;

encoder = old_conn_state->best_encoder;
@@ -847,7 +848,8 @@ void drm_atomic_helper_commit_modeset_enables(struct 
drm_device *dev,
if (!connector || !connector->state->best_encoder)
continue;

-   if (!connector->state->crtc->state->active)
+   if (!connector->state->crtc->state->active ||
+   !needs_modeset(connector->state->crtc->state))
continue;

encoder = connector->state->best_encoder;
-- 
2.1.4



[PATCH] drm/i915/skl: fix semicolon.cocci warnings

2015-03-26 Thread kbuild test robot
drivers/gpu/drm/i915/intel_pm.c:2913:4-5: Unneeded semicolon


 Removes unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Tvrtko Ursulin 
Signed-off-by: Fengguang Wu 
---

 intel_pm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2910,7 +2910,7 @@ static bool skl_compute_plane_wm(const s
break;
case 8:
WARN(1, "Unsupported pixel depth for rotation");
-   };
+   }
}
y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);


[PATCH] xf86drm: Fix ioctl struct clearing in drmAgpEnable

2015-03-26 Thread Connor Behan
On 26/03/15 08:06 PM, Emil Velikov wrote:
> On 24 March 2015 at 17:53, Connor Behan  wrote:
>> This one is a bit harder to notice.
>>
> Plus not so widely used any more :-)
>
> Mildly related - with EXA support for the r128 ddx done for a while
> now, do you have any plans on updating the dri module to dri2 ?
>
Yes, that is still the eventual goal. I'm looking at how the radeon
kernel module is setup these days. So I should be able to start porting
r128 to KMS at some point this year.

Thanks for the interest!
>> Signed-off-by: Connor Behan 
> Reviewed-by: Emil Velikov 
>
> Thanks !
> Emil


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/7ee67ef8/attachment-0001.sig>


intel_sprite_get_colorkey oops

2015-03-26 Thread Tommi Rantala
Hello,

Trinity discovered oopses with the i915 colorkey ioctls, reproducible
on my system with this:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define GET DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY,
struct drm_intel_sprite_colorkey)

int main(int argc, char **argv)
{
int fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
for (int i=0; i < 128; ++i) {
printf("get=%d\n", i);
struct drm_intel_sprite_colorkey colorkey = { .plane_id = i };
ioctl(fd, GET, &colorkey);
}
for (int i=0; i < 128; ++i) {
printf("set=%d\n", i);
struct drm_intel_sprite_colorkey colorkey = { .plane_id = i };
ioctl(fd, DRM_IOCTL_I915_SET_SPRITE_COLORKEY, &colorkey);
}
return 0;
}

$ ./main /dev/dri/card0
get=0
get=1
get=2
get=3
get=4
get=5
get=6
get=7
get=8
get=9
get=10
get=11
get=12
get=13
get=14
get=15
get=16
get=17

[   40.467123] BUG: unable to handle kernel NULL pointer dereference
at   (null)
[   40.475012] IP: [<  (null)>]   (null)
[   40.480094] PGD 1728cd067 PUD 17163c067 PMD 0
[   40.484589] Oops: 0010 [#1] SMP KASAN
[   40.488297] CPU: 0 PID: 2198 Comm: main Not tainted 4.0.0-rc5+ #87
[   40.501666] task: 8800c66cd380 ti: 88017279 task.ti:
88017279
[   40.509179] RIP: 0010:[<>]  [<  (null)>]
   (null)
[   40.516702] RSP: 0018:880172797d30  EFLAGS: 00010246
[   40.522037] RAX: ed002e7acbe2 RBX: 88017401d000 RCX: 0007
[   40.529200] RDX:  RSI: 880172797dd8 RDI: 880173d65c00
[   40.536361] RBP: 880172797d68 R08:  R09: 
[   40.543523] R10:  R11:  R12: 
[   40.550686] R13: 880173d65cd8 R14: 880172797dd8 R15: 880173d65c00
[   40.557852] FS:  7f09a72e6700() GS:880175c0()
knlGS:
[   40.565976] CS:  0010 DS:  ES:  CR0: 80050033
[   40.571744] CR2:  CR3: 00017261c000 CR4: 000406f0
[   40.578907] Stack:
[   40.580926]  81b4a437 880172797d68 88017401d000
88017147
[   40.588394]  0014 fff2 8271c400
880172797e88
[   40.595864]  818acbbc 880172797e18 8165d7c2
8165d660
[   40.603335] Call Trace:
[   40.605797]  [] ? intel_sprite_get_colorkey+0x97/0xc0
[   40.612438]  [] drm_ioctl+0x27c/0x890
[   40.617687]  [] ? avc_has_perm+0x182/0x320
[   40.623371]  [] ? avc_has_perm+0x20/0x320
[   40.628966]  [] ? intel_sprite_set_colorkey+0x260/0x260
[   40.635785]  [] ? inode_has_perm.isra.28+0x7c/0xa0
[   40.642169]  [] ? _raw_spin_unlock_irq+0x2b/0x40
[   40.648376]  [] do_vfs_ioctl+0x3cf/0x720
[   40.653887]  [] ? selinux_file_ioctl+0x6a/0x130
[   40.660008]  [] SyS_ioctl+0x81/0xa0
[   40.665083]  [] system_call_fastpath+0x12/0x17
[   40.671112] Code:  Bad RIP value.
[   40.674465] RIP  [<  (null)>]   (null)
[   40.679634]  RSP 
[   40.683134] CR2: 
[   40.686498] ---[ end trace 9292d9b4aba8dfe9 ]---


[git pull] drm intel fixes

2015-03-26 Thread Dave Airlie

Hi Linus,

here is the complete set of i915 bug/warn/refcounting fixes.

Dave.

The following changes since commit 90a5a895cc8b284ac522757a01de15e36710c2b9:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-03-23 
10:16:13 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 9822393d23ba9129396ab9308dbb8ce10ae74751:

  Merge tag 'drm-intel-fixes-2015-03-26' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-03-27 07:39:45 
+1000)


Chris Wilson (1):
  drm/i915: Keep ring->active_list and ring->requests_list consistent

Damien Lespiau (2):
  drm/i915: Don't try to reference the fb in get_initial_plane_config()
  drm/i915: Fix atomic state when reusing the firmware fb

Daniel Vetter (2):
  drm: Fixup racy refcounting in plane_force_disable
  drm/i915: Fixup legacy plane->crtc link for initial fb config

Dave Airlie (1):
  Merge tag 'drm-intel-fixes-2015-03-26' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

 drivers/gpu/drm/drm_crtc.c   | 13 +---
 drivers/gpu/drm/i915/i915_gem.c  | 38 
 drivers/gpu/drm/i915/intel_display.c | 18 -
 3 files changed, 35 insertions(+), 34 deletions(-)


[PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl

2015-03-26 Thread Tommi Rantala
Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.

Signed-off-by: Tommi Rantala 
---
 include/uapi/drm/i915_drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..0e9c835 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -270,7 +270,7 @@ typedef struct _drm_i915_sarea {
 #define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE   DRM_IOW(DRM_COMMAND_BASE + 
DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
 #define DRM_IOCTL_I915_OVERLAY_ATTRS   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
 #define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
-#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
 #define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE + 
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
 #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE  DRM_IOWR (DRM_COMMAND_BASE + 
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
 #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE + 
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
-- 
2.1.0



[PATCH v3 8/8] drm/exynos: dsi: do not set TE GPIO direction by input

2015-03-26 Thread Hyungwon Hwang
On some board, TE GPIO should be configured properly thoughout pinctrl driver
as an wakeup interrupt. So this gpio should be configurable in the board's DT,
not being requested as a input pin.

Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
 - None

Changes for v3:
 - None

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index d382511..230082a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1316,15 +1316,15 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi)
goto out;
}

-   ret = gpio_request_one(dsi->te_gpio, GPIOF_IN, "te_gpio");
+   ret = gpio_request(dsi->te_gpio, "te_gpio");
if (ret) {
dev_err(dsi->dev, "gpio request failed with %d\n", ret);
goto out;
}

te_gpio_irq = gpio_to_irq(dsi->te_gpio);
-
irq_set_status_flags(te_gpio_irq, IRQ_NOAUTOEN);
+
ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
IRQF_TRIGGER_RISING, "TE", dsi);
if (ret) {
-- 
1.9.1



[PATCH v3 7/8] drm/exynos: dsi: add support for MIC driver as a bridge

2015-03-26 Thread Hyungwon Hwang
MIC must be initilized by MIPI DSI when it is being bound.

Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
 - None

Changes for v3:
 - None

 .../devicetree/bindings/video/exynos_dsim.txt  | 23 ++---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 24 ++
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 8b12bfe..9112b10 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -31,10 +31,19 @@ Video interfaces:
   Device node can contain video interface port nodes according to [2].
   The following are properties specific to those nodes:

-  port node:
-- reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port;
+  port node inbound:
+- reg: (required) must be 0.
+  port node outbound:
+- reg: (required) must be 1.

-  endpoint node of DSI port (reg = 1):
+  endpoint node connected from mic node (reg = 0):
+- remote-endpoint: specifies the endpoint in mic node. This node is 
required
+  for Exynos5433 mipi dsi. So mic can access to panel node
+  thoughout this dsi node.
+  endpoint node connected to panel node (reg = 1):
+- remote-endpoint: specifies the endpoint in panel node. This node is
+  required in all kinds of exynos mipi dsi to represent
+  the connection between mipi dsi and panel.
 - samsung,burst-clock-frequency: specifies DSI frequency in high-speed 
burst
   mode
 - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
@@ -73,7 +82,15 @@ Example:
#address-cells = <1>;
#size-cells = <0>;

+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <&mic_to_decon>;
+   };
+   };
+
port at 1 {
+   reg = <1>;
dsi_ep: endpoint {
reg = <0>;
samsung,burst-clock-frequency = 
<5>;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index d1ecd0f..d382511 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -282,6 +283,7 @@ struct exynos_dsi {
struct list_head transfer_list;

struct exynos_dsi_driver_data *driver_data;
+   struct device_node *bridge_node;
 };

 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1778,7 +1780,22 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)

ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
 &dsi->esc_clk_rate);
+   if (ret < 0)
+   goto end;
+
+   of_node_put(ep);
+
+   ep = of_graph_get_next_endpoint(node, NULL);
+   if (!ep) {
+   ret = -ENXIO;
+   goto end;
+   }

+   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+   if (!dsi->bridge_node) {
+   ret = -ENXIO;
+   goto end;
+   }
 end:
of_node_put(ep);

@@ -1791,6 +1808,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
struct exynos_drm_display *display = dev_get_drvdata(dev);
struct exynos_dsi *dsi = display_to_dsi(display);
struct drm_device *drm_dev = data;
+   struct drm_bridge *bridge;
int ret;

ret = exynos_drm_create_enc_conn(drm_dev, display);
@@ -1800,6 +1818,12 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
return ret;
}

+   bridge = of_drm_find_bridge(dsi->bridge_node);
+   if (bridge) {
+   display->encoder->bridge = bridge;
+   drm_bridge_attach(drm_dev, bridge);
+   }
+
return mipi_dsi_host_register(&dsi->dsi_host);
 }

-- 
1.9.1



[PATCH v3 6/8] drm/exynos: dsi: add support for Exynos5433

2015-03-26 Thread Hyungwon Hwang
This patch adds support for Exynos5433 mipi dsi.

Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
 - change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
 Hyungwon Hwang by the previous author's will
Changes for v3:
 - Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
 in version 2.
 - use defines for more readable code
 - fix typos
 .../devicetree/bindings/video/exynos_dsim.txt  |  1 +
 drivers/gpu/drm/exynos/Kconfig |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 69 +-
 3 files changed, 68 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 39940ca..8b12bfe 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -6,6 +6,7 @@ Required properties:
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
*/
+   "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index f78f3ef..e873502 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -47,7 +47,7 @@ config DRM_EXYNOS_DPI

 config DRM_EXYNOS_DSI
bool "EXYNOS DRM MIPI-DSI driver support"
-   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON)
+   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || 
DRM_EXYNOS7_DECON)
select DRM_MIPI_DSI
select DRM_PANEL
default n
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2d9a249..d1ecd0f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -131,6 +131,7 @@
 #define DSIM_INT_PLL_STABLE(1 << 31)
 #define DSIM_INT_SW_RST_RELEASE(1 << 30)
 #define DSIM_INT_SFR_FIFO_EMPTY(1 << 29)
+#define DSIM_INT_SFR_HDR_FIFO_EMPTY(1 << 28)
 #define DSIM_INT_BTA   (1 << 25)
 #define DSIM_INT_FRAME_DONE(1 << 24)
 #define DSIM_INT_RX_TIMEOUT(1 << 21)
@@ -179,6 +180,8 @@

 /* DSIM_PHYCTRL */
 #define DSIM_PHYCTRL_ULPS_EXIT(x)  (((x) & 0x1ff) << 0)
+#define DSIM_PHYCTRL_B_DPHYCTL_VREG_LP (1 << 30)
+#define DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP (1 << 14)

 /* DSIM_PHYTIMING */
 #define DSIM_PHYTIMING_LPX(x)  ((x) << 8)
@@ -206,7 +209,9 @@
 #define DSI_WRITE(dsi, reg, val)   writel((val), REG((dsi), (reg)))
 #define DSI_READ(dsi, reg) readl(REG((dsi), (reg)))

-static char *clk_names[2] = { "bus_clk", "sclk_mipi" };
+static char *clk_names[5] = { "bus_clk", "sclk_mipi",
+   "phyclk_mipidphy0_bitclkdiv8", "phyclk_mipidphy0_rxclkesc0",
+   "sclk_rgb_vclk_to_dsim0" };

 enum exynos_dsi_transfer_type {
EXYNOS_DSI_TX,
@@ -335,6 +340,30 @@ static unsigned int regs[] = {
[DSIM_PHYTIMING2_REG] =  0x6c,
 };

+static unsigned int exynos5433_regs[] = {
+   [DSIM_STATUS_REG] = 0x04,
+   [DSIM_SWRST_REG] = 0x0C,
+   [DSIM_CLKCTRL_REG] = 0x10,
+   [DSIM_TIMEOUT_REG] = 0x14,
+   [DSIM_CONFIG_REG] = 0x18,
+   [DSIM_ESCMODE_REG] = 0x1C,
+   [DSIM_MDRESOL_REG] = 0x20,
+   [DSIM_MVPORCH_REG] = 0x24,
+   [DSIM_MHPORCH_REG] = 0x28,
+   [DSIM_MSYNC_REG] = 0x2C,
+   [DSIM_INTSRC_REG] = 0x34,
+   [DSIM_INTMSK_REG] = 0x38,
+   [DSIM_PKTHDR_REG] = 0x3C,
+   [DSIM_PAYLOAD_REG] = 0x40,
+   [DSIM_RXFIFO_REG] = 0x44,
+   [DSIM_FIFOCTRL_REG] = 0x4C,
+   [DSIM_PLLCTRL_REG] = 0x94,
+   [DSIM_PHYCTRL_REG] = 0xA4,
+   [DSIM_PHYTIMING_REG] = 0xB4,
+   [DSIM_PHYTIMING1_REG] = 0xB8,
+   [DSIM_PHYTIMING2_REG] = 0xBC,
+};
+
 enum values {
RESET_TYPE,
PLL_TIMER,
@@ -371,6 +400,24 @@ static unsigned int values[] = {
[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
 };

+static unsigned int exynos5433_values[] = {
+   [RESET_TYPE] = DSIM_FUNCRST,
+   [PLL_TIMER] = 22200,
+   [STOP_STATE_CNT] = 0xa,
+   [PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
+   [PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
+   [PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
+   [PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
+   [PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
+   [PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
+   [PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
+   [PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
+   [PHYTIMING_CLK_TRAIL] = DSIM_PHY

[PATCH v3 5/8] drm/exynos: dsi: generalize register setting and clock control

2015-03-26 Thread Hyungwon Hwang
This patch makes the driver use arrays for clocks, register address,
and values. By doing this, it becomes easier to add support for another
SoC.

Signed-off-by: Hyungwon Hwang 
---
Changes for v3:
 - Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
 in version 2.
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 347 
 1 file changed, 218 insertions(+), 129 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 4af18b2f..2d9a249 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -33,38 +33,6 @@
 /* returns true iff both arguments logically differs */
 #define NEQV(a, b) (!(a) ^ !(b))

-#define DSIM_STATUS_REG0x0 /* Status register */
-#define DSIM_SWRST_REG 0x4 /* Software reset register */
-#define DSIM_CLKCTRL_REG   0x8 /* Clock control register */
-#define DSIM_TIMEOUT_REG   0xc /* Time out register */
-#define DSIM_CONFIG_REG0x10/* Configuration register */
-#define DSIM_ESCMODE_REG   0x14/* Escape mode register */
-
-/* Main display image resolution register */
-#define DSIM_MDRESOL_REG   0x18
-#define DSIM_MVPORCH_REG   0x1c/* Main display Vporch register */
-#define DSIM_MHPORCH_REG   0x20/* Main display Hporch register */
-#define DSIM_MSYNC_REG 0x24/* Main display sync area register */
-
-/* Sub display image resolution register */
-#define DSIM_SDRESOL_REG   0x28
-#define DSIM_INTSRC_REG0x2c/* Interrupt source register */
-#define DSIM_INTMSK_REG0x30/* Interrupt mask register */
-#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register 
*/
-#define DSIM_PAYLOAD_REG   0x38/* Payload FIFO register */
-#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */
-#define DSIM_FIFOTHLD_REG  0x40/* FIFO threshold level register */
-#define DSIM_FIFOCTRL_REG  0x44/* FIFO status and control register */
-
-/* FIFO memory AC characteristic register */
-#define DSIM_PLLCTRL_REG   0x4c/* PLL control register */
-#define DSIM_PHYACCHR_REG  0x54/* D-PHY AC characteristic register */
-#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
-#define DSIM_PHYCTRL_REG   0x5c
-#define DSIM_PHYTIMING_REG 0x64
-#define DSIM_PHYTIMING1_REG0x68
-#define DSIM_PHYTIMING2_REG0x6c
-
 /* DSIM_STATUS */
 #define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
 #define DSIM_STOP_STATE_CLK(1 << 8)
@@ -128,8 +96,8 @@

 /* DSIM_MDRESOL */
 #define DSIM_MAIN_STAND_BY (1 << 31)
-#define DSIM_MAIN_VRESOL(x)(((x) & 0x7ff) << 16)
-#define DSIM_MAIN_HRESOL(x)(((x) & 0X7ff) << 0)
+#define DSIM_MAIN_VRESOL(x, num_bits)  (((x) & ((1 << (num_bits)) - 1)) << 16)
+#define DSIM_MAIN_HRESOL(x, num_bits)  (((x) & ((1 << (num_bits)) - 1)) << 0)

 /* DSIM_MVPORCH */
 #define DSIM_CMD_ALLOW(x)  ((x) << 28)
@@ -234,6 +202,12 @@
 #define DSI_XFER_TIMEOUT_MS100
 #define DSI_RX_FIFO_EMPTY  0x3082

+#define REG(dsi, reg)  ((dsi)->reg_base + dsi->driver_data->regs[(reg)])
+#define DSI_WRITE(dsi, reg, val)   writel((val), REG((dsi), (reg)))
+#define DSI_READ(dsi, reg) readl(REG((dsi), (reg)))
+
+static char *clk_names[2] = { "bus_clk", "sclk_mipi" };
+
 enum exynos_dsi_transfer_type {
EXYNOS_DSI_TX,
EXYNOS_DSI_RX,
@@ -261,10 +235,15 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_CMD_LPM BIT(2)

 struct exynos_dsi_driver_data {
+   unsigned int *regs;
unsigned int plltmr_reg;
-
unsigned int has_freqband:1;
unsigned int has_clklane_stop:1;
+   unsigned int num_clks;
+   unsigned int max_freq;
+   unsigned int wait_for_reset;
+   unsigned int num_bits_resol;
+   unsigned int *values;
 };

 struct exynos_dsi {
@@ -277,8 +256,7 @@ struct exynos_dsi {

void __iomem *reg_base;
struct phy *phy;
-   struct clk *sclk_clk;
-   struct clk *bus_clk;
+   struct clk **clks;
struct regulator_bulk_data supplies[2];
int irq;
int te_gpio;
@@ -309,25 +287,133 @@ static inline struct exynos_dsi *display_to_dsi(struct 
exynos_drm_display *d)
return container_of(d, struct exynos_dsi, display);
 }

+enum regs {
+   DSIM_STATUS_REG,/* Status register */
+   DSIM_SWRST_REG, /* Software reset register */
+   DSIM_CLKCTRL_REG,   /* Clock control register */
+   DSIM_TIMEOUT_REG,   /* Time out register */
+   DSIM_CONFIG_REG,/* Configuration register */
+   DSIM_ESCMODE_REG,   /* Escape mode register */
+   DSIM_MDRESOL_REG,
+   DSIM_MVPORCH_REG,   /* Main display Vporch register */
+   DSIM_MHPORCH_REG,   /* Main display Hporch register */
+

[PATCH v3 4/8] drm/exynos: dsi: rename pll_clk to sclk_clk

2015-03-26 Thread Hyungwon Hwang
This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
is actually not the pll input clock for dsi. The pll input clock comes
from the board's oscillator directly.

Signed-off-by: Hyungwon Hwang 
---
Changes for v3:
 - Newly added
 .../devicetree/bindings/video/exynos_dsim.txt  |  6 ++---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 31 --
 2 files changed, 14 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 802aa7e..39940ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -10,13 +10,13 @@ Required properties:
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
 entry in clock-names
-  - clock-names: should include "bus_clk"and "pll_clk" entries
+  - clock-names: should include "bus_clk"and "sclk_mipi" entries
   - phys: list of phy specifiers, must contain an entry for each required
 entry in phy-names
   - phy-names: should include "dsim" entry
   - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
   - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
-  - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
+  - samsung,pll-clock-frequency: specifies frequency of the oscillator clock
   - #address-cells, #size-cells: should be set respectively to <1> and <0>
 according to DSI host bindings (see MIPI DSI bindings [1])

@@ -48,7 +48,7 @@ Example:
reg = <0x11C8 0x1>;
interrupts = <0 79 0>;
clocks = <&clock 286>, <&clock 143>;
-   clock-names = "bus_clk", "pll_clk";
+   clock-names = "bus_clk", "sclk_mipi";
phys = <&mipi_phy 1>;
phy-names = "dsim";
vddcore-supply = <&vusb_reg>;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 05fe93d..4af18b2f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -277,7 +277,7 @@ struct exynos_dsi {

void __iomem *reg_base;
struct phy *phy;
-   struct clk *pll_clk;
+   struct clk *sclk_clk;
struct clk *bus_clk;
struct regulator_bulk_data supplies[2];
int irq;
@@ -431,16 +431,7 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi 
*dsi,
u16 m;
u32 reg;

-   clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
-
-   fin = clk_get_rate(dsi->pll_clk);
-   if (!fin) {
-   dev_err(dsi->dev, "failed to get PLL clock frequency\n");
-   return 0;
-   }
-
-   dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
-
+   fin = dsi->pll_clk_rate;
fout = exynos_dsi_pll_find_pms(dsi, fin, freq, &p, &m, &s);
if (!fout) {
dev_err(dsi->dev,
@@ -1308,10 +1299,10 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
goto err_bus_clk;
}

-   ret = clk_prepare_enable(dsi->pll_clk);
+   ret = clk_prepare_enable(dsi->sclk_clk);
if (ret < 0) {
dev_err(dsi->dev, "cannot enable pll clock %d\n", ret);
-   goto err_pll_clk;
+   goto err_sclk_clk;
}

ret = phy_power_on(dsi->phy);
@@ -1323,8 +1314,8 @@ static int exynos_dsi_poweron(struct exynos_dsi *dsi)
return 0;

 err_phy:
-   clk_disable_unprepare(dsi->pll_clk);
-err_pll_clk:
+   clk_disable_unprepare(dsi->sclk_clk);
+err_sclk_clk:
clk_disable_unprepare(dsi->bus_clk);
 err_bus_clk:
regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
@@ -1350,7 +1341,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)

phy_power_off(dsi->phy);

-   clk_disable_unprepare(dsi->pll_clk);
+   clk_disable_unprepare(dsi->sclk_clk);
clk_disable_unprepare(dsi->bus_clk);

ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
@@ -1720,10 +1711,10 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
return -EPROBE_DEFER;
}

-   dsi->pll_clk = devm_clk_get(dev, "pll_clk");
-   if (IS_ERR(dsi->pll_clk)) {
-   dev_info(dev, "failed to get dsi pll input clock\n");
-   ret = PTR_ERR(dsi->pll_clk);
+   dsi->sclk_clk = devm_clk_get(dev, "sclk_mipi");
+   if (IS_ERR(dsi->sclk_clk)) {
+   dev_info(dev, "failed to get dsi sclk clock\n");
+   ret = PTR_ERR(dsi->sclk_clk);
goto err_del_component;
}

-- 
1.9.1



[PATCH v3 3/8] drm/exynos: mic: add MIC driver

2015-03-26 Thread Hyungwon Hwang
MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.

Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
 - make mic driver to be registered by exynos drm driver instead as a module
 driver
 - change the description of mic driver in documentation
 - add module author at the top of the source file removing MODULE_OWNER,
 MODULE_DESCRIPTION, MODULE_LICENSE

Changes for v3:
 - move if statement out of function, so that the function is not called
 unnecessarily
 - Make it use syscon framework for controlling system register

 .../devicetree/bindings/video/exynos-mic.txt   |  51 +++
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 490 +
 6 files changed, 552 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c

diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt 
b/Documentation/devicetree/bindings/video/exynos-mic.txt
new file mode 100644
index 000..0fba2ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-mic.txt
@@ -0,0 +1,51 @@
+Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC)
+
+MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is
+not capable to transfer high resoltuion frame data as decon can send. MIC
+solves this problem by compressing the frame data by 1/2 before it is
+transferred through mipi dsi. The compressed frame data must be uncompressed in
+the panel PCB.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-mic".
+- reg: physical base address and length of the MIC registers set and system
+   register of mic.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0".
+- samsung,disp-syscon: the reference node for syscon for DISP block.
+- ports: contains a port which is connected to decon node and dsi node.
+address-cells and size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the
+   decon node or dsi node. The reg value must be 0 and 1 respectively.
+
+Example:
+SoC specific DT entry:
+mic: mic at 1393 {
+   compatible = "samsung,exynos5433-mic";
+   reg = <0x1393 0x48>;
+   clocks = <&cmu_disp CLK_PCLK_MIC0>,
+  <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>;
+   clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0";
+   samsung,disp-syscon = <&syscon_disp>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   mic_to_decon: endpoint {
+   remote-endpoint = <&decon_to_mic>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   mic_to_dsi: endpoint {
+   remote-endpoint = <&dsi_to_mic>;
+   };
+   };
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d9dc408..f78f3ef 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -103,3 +103,9 @@ config DRM_EXYNOS_GSC
depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use Exynos GSC for DRM.
+
+config DRM_EXYNOS_MIC
+   bool "Exynos DRM MIC"
+   depends on (DRM_EXYNOS && DRM_EXYNOS5433_DECON)
+   help
+ Choose this option if you want to use Exynos MIC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index fbd084d..7de0b10 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -22,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+= exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4d6ad28..00cbaa2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_

[PATCH v3 2/8] of: add helper for getting endpoint node of specific identifiers

2015-03-26 Thread Hyungwon Hwang
When there are multiple ports or multiple endpoints in a port, they have to be
distinguished by the value of reg property. It is common. The drivers can get
the specific endpoint in the specific port via this function. Now the drivers
have to implement this code in themselves or have to force the order of dt nodes
to get the right node.

Signed-off-by: Hyungwon Hwang 
Acked-by: Rob Herring 
---
Changes for v2:
 - None

Changes for v3:
 - None

 drivers/of/base.c| 33 +
 include/linux/of_graph.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index adb8764..ffc2235 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2165,6 +2165,39 @@ struct device_node *of_graph_get_next_endpoint(const 
struct device_node *parent,
 EXPORT_SYMBOL(of_graph_get_next_endpoint);

 /**
+ * of_graph_get_endpoint_by_regs() - get endpoint node of specific identifiers
+ * @parent: pointer to the parent device node
+ * @port_reg: identifier (value of reg property) of the parent port node
+ * @reg: identifier (value of reg property) of the endpoint node
+ *
+ * Return: An 'endpoint' node pointer which is identified by reg and at the 
same
+ * is the child of a port node identified by port_reg. reg and port_reg are
+ * ignored when they are -1.
+ */
+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg)
+{
+   struct of_endpoint endpoint;
+   struct device_node *node, *prev_node = NULL;
+
+   while (1) {
+   node = of_graph_get_next_endpoint(parent, prev_node);
+   of_node_put(prev_node);
+   if (!node)
+   break;
+
+   of_graph_parse_endpoint(node, &endpoint);
+   if (((port_reg == -1) || (endpoint.port == port_reg)) &&
+   ((reg == -1) || (endpoint.id == reg)))
+   return node;
+
+   prev_node = node;
+   }
+
+   return NULL;
+}
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e859eb7 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -31,6 +31,8 @@ int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -49,6 +51,12 @@ static inline struct device_node *of_graph_get_next_endpoint(
return NULL;
 }

+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1



[PATCH v3 1/8] drm/exynos: add Exynos5433 decon driver

2015-03-26 Thread Hyungwon Hwang
From: Joonyoung Shim 

DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Hyungwon Hwang 
---
Changes for v2:
 - change file names and variable names of decon to represnt exynos5433 instead
 of exynos to distinguish them from exynos7 decon

Changes for v3:
 - fail fast when the proper image format is not set
 - remove unnecessary checking code
 - add and modify the function to make DPMS work well
 .../devicetree/bindings/video/exynos5433-decon.txt |  65 ++
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 665 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 include/video/exynos5433_decon.h   | 163 +
 7 files changed, 904 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 create mode 100644 include/video/exynos5433_decon.h

diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
new file mode 100644
index 000..377afbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-decon";
+- reg: physical base address and length of the DECON registers set.
+- interrupts: should contain a list of all DECON IP block interrupts in the
+ order: VSYNC, LCD_SYSTEM. The interrupt specifier format
+ depends on the interrupt controller used.
+- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
+  in the same order as they were listed in the interrupts
+  property.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+  "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+  "sclk_decon_eclk"
+- ports: contains a port which is connected to mic node. address-cells and
+size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the mic
+   node. The reg value muset be 0.
+- i80-if-timings: specify whether the panel which is connected to decon uses
+ i80 lcd interface or mipi video interface. This node contains
+ no timing information as that of fimd does. Because there is
+ no register in decon to specify i80 interface timing value,
+ it is not needed, but make it remain to use same kind of node
+ in fimd and exynos7 decon.
+
+Example:
+SoC specific DT entry:
+decon: decon at 1380 {
+   compatible = "samsung,exynos5433-decon";
+   reg = <0x1380 0x2104>;
+   clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>,
+   <&cmu_disp CLK_ACLK_XIU_DECON0X>,
+   <&cmu_disp CLK_PCLK_SMMU_DECON0X>,
+   <&cmu_disp CLK_SCLK_DECON_VCLK>,
+   <&cmu_disp CLK_SCLK_DECON_ECLK>;
+   clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x",
+   "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk";
+   interrupt-names = "vsync", "lcd_sys";
+   interrupts = <0 202 0>, <0 203 0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <&mic_to_decon>;
+   };
+   };
+   };
+};
+
+Board specific DT entry:
+&decon {
+   i80-if-timings {
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index c8001c2..d9dc408 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,6 +24,12 @@ config DRM_EXYNOS_FIMD
help
  Choose this option if you want to use Exynos FIMD for DRM.

+config DRM_EXYNOS5433_DECON
+   bool "Exynos5433 DRM DECON"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos5433 DECON for DRM.
+
 config DRM_EXYNOS7_DECON
bool "Exynos DRM DECON"
depends on DRM_EXYNOS
diff --git a/drive

[PATCH v3 0/8] Add drivers for Exynos5433 display

2015-03-26 Thread Hyungwon Hwang
This patchset is based on the git(branch name: exynos-drm-next) which is
maintained by Inki Dae.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/...

This patchset adds 2 new device drivers, decon and mic, and adds support for
Exynos5433 mipi dsi. To enable display in a Exynos5433 board, decon(display
controller), MIC(Mobile image compressor), mipi dsi, and panel have to be turned
on. This patchset contains support for 3 drivers for SoC level devices.

Changes for v2:
- change config, file, and variable names of decon to represnt exynos5433
instead of exynos to distinguish them from exynos7 decon
- change the initialization order of decon to make it initialized in order like
FIMD or exynos7 decon
- make mic driver to be registered by exynos drm driver instead as a module
driver
- change the description of mic driver in documentation
- add module author at the top of the source file removing MODULE_OWNER,
MODULE_DESCRIPTION, MODULE_LICENSE
- change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
Hyungwon Hwang by the previous author's will

Changes for v3:
< Decon >
 - fail fast when the proper image format is not set
 - remove unnecessary checking code
 - add and modify the function to make DPMS work well
< MIC >
 - move if statement out of function, so that the function is not called
 unnecessarily
 - Make it use syscon framework for controlling system register
< DSI >
 - separate the previous one patch to three
   - renaming patch: rename pll clock to sclk clock
   - generalizing patch: generalize the way to getting address and values
   - Exynos5433 patch: adds support for Exynos5433 dsi
 - use defines for more readable code
 - fix typos

Hyungwon Hwang (7):
  of: add helper for getting endpoint node of specific identifiers
  drm/exynos: mic: add MIC driver
  drm/exynos: dsi: rename pll_clk to sclk_clk
  drm/exynos: dsi: generalize register setting and clock control
  drm/exynos: dsi: add support for Exynos5433
  drm/exynos: dsi: add support for MIC driver as a bridge
  drm/exynos: dsi: do not set TE GPIO direction by input

Joonyoung Shim (1):
  drm/exynos: add Exynos5433 decon driver

 .../devicetree/bindings/video/exynos-mic.txt   |  51 ++
 .../devicetree/bindings/video/exynos5433-decon.txt |  65 ++
 .../devicetree/bindings/video/exynos_dsim.txt  |  30 +-
 drivers/gpu/drm/exynos/Kconfig |  14 +-
 drivers/gpu/drm/exynos/Makefile|   2 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 665 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   6 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   2 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 453 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 490 +++
 drivers/of/base.c  |  33 +
 include/linux/of_graph.h   |   8 +
 include/video/exynos5433_decon.h   | 163 +
 13 files changed, 1832 insertions(+), 150 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c
 create mode 100644 include/video/exynos5433_decon.h

--
1.9.1



[PATCH v2 4/6] drm/exynos: dsi: add support for Exynos5433 SoC

2015-03-26 Thread Hyungwon Hwang
Dear Daniel,

On Wed, 18 Mar 2015 09:52:33 +
Daniel Stone  wrote:

> Hi,
> 
> On 18 March 2015 at 08:16, Hyungwon Hwang 
> wrote:
> > +#define REG(dsi, reg)  ((dsi)->reg_base +
> > dsi->driver_data->regs[(reg)])
> 
> This seems like a good change in general, but please split it up: it
> makes bisection much easier if you have one patch which adds no
> functionality and should have exactly the same behaviour, and then
> another patch which introduces your changes.
> 

Yes. That also looks good to me.

> > @@ -431,15 +579,11 @@ static unsigned long
> > exynos_dsi_set_pll(struct exynos_dsi *dsi, u16 m;
> > u32 reg;
> >
> > -   clk_set_rate(dsi->pll_clk, dsi->pll_clk_rate);
> > -
> > -   fin = clk_get_rate(dsi->pll_clk);
> > -   if (!fin) {
> > -   dev_err(dsi->dev, "failed to get PLL clock
> > frequency\n");
> > -   return 0;
> > -   }
> > -
> > -   dev_dbg(dsi->dev, "PLL input frequency: %lu\n", fin);
> > +   /*
> > +* The input PLL clock for MIPI DSI in Exynos5433 seems to
> > be fixed
> > +* by OSC CLK.
> > +*/
> > +   fin = 24 * MHZ;
> 
> Er, is this always true on other platforms as well? Shouldn't this be
> a part of the DeviceTree description?
> 
> > @@ -509,7 +656,7 @@ static int exynos_dsi_enable_clock(struct
> > exynos_dsi *dsi) dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu,
> > esc_clk = %lu\n", hs_clk, byte_clk, esc_clk);
> >
> > -   reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
> > +   reg = readl(REG(dsi, DSIM_CLKCTRL_REG));
> 
> Instead of this readl(REG()) pattern you have everywhere, maybe it
> would be easier to introduce a dsi_read_reg(dsi, reg_enum_value)
> helper, and the same for write_reg.
> 

Yes. That's resonable.

> > @@ -1720,18 +1873,16 @@ static int exynos_dsi_probe(struct
> > platform_device *pdev) return -EPROBE_DEFER;
> > }
> >
> > -   dsi->pll_clk = devm_clk_get(dev, "pll_clk");
> > -   if (IS_ERR(dsi->pll_clk)) {
> > -   dev_info(dev, "failed to get dsi pll input
> > clock\n");
> > -   ret = PTR_ERR(dsi->pll_clk);
> > -   goto err_del_component;
> > -   }
> > -
> > -   dsi->bus_clk = devm_clk_get(dev, "bus_clk");
> > -   if (IS_ERR(dsi->bus_clk)) {
> > -   dev_info(dev, "failed to get dsi bus clock\n");
> > -   ret = PTR_ERR(dsi->bus_clk);
> > -   goto err_del_component;
> > +   dsi->clks = devm_kzalloc(dev,
> > +   sizeof(*dsi->clks) *
> > dsi->driver_data->num_clks,
> > +   GFP_KERNEL);
> > +   for (i = 0; i < dsi->driver_data->num_clks; i++) {
> > +   dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
> > +   if (IS_ERR(dsi->clks[i])) {
> > +   dev_info(dev, "failed to get dsi pll input
> > clock\n");
> 
> This error message seems wrong; it should contain the name of the
> actual failing clock.
> 

OK.

Best regards,
Hyungwon Hwang

> Cheers,
> Daniel



[PATCH v2 4/4] drm/msm/mdp5: Enable DSI connector in msm drm driver

2015-03-26 Thread Hai Li
This change adds the support in mdp5 kms driver for single
and dual DSI. Dual DSI case depends on the framework API
and sequence change to support dual data path.

v1: Initial change
v2: Address Rob Clark's comment
- Separate command mode encoder to a new file mdp5_cmd_encoder.c
- Rebase to not depend on msm_drm_sub_dev change

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Makefile|   3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   4 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 343 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  43 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  70 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  28 +-
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 8 files changed, 497 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 5c144cc..ab20867 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -53,6 +53,7 @@ msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
 msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
dsi/dsi_host.o \
dsi/dsi_manager.o \
-   dsi/dsi_phy.o
+   dsi/dsi_phy.o \
+   mdp/mdp5/mdp5_cmd_encoder.o

 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 6c467fb..2c9a9dc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -68,6 +68,8 @@ const struct mdp5_cfg_hw msm8x74_config = {
},
.intfs = {
[0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
[3] = INTF_HDMI,
},
.max_clk = 2,
@@ -125,6 +127,8 @@ const struct mdp5_cfg_hw apq8084_config = {
},
.intfs = {
[0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
[3] = INTF_HDMI,
},
.max_clk = 32000,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
new file mode 100644
index 000..e4e8956
--- /dev/null
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "mdp5_kms.h"
+
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+struct mdp5_cmd_encoder {
+   struct drm_encoder base;
+   struct mdp5_interface intf;
+   bool enabled;
+   uint32_t bsc;
+};
+#define to_mdp5_cmd_encoder(x) container_of(x, struct mdp5_cmd_encoder, base)
+
+static struct mdp5_kms *get_kms(struct drm_encoder *encoder)
+{
+   struct msm_drm_private *priv = encoder->dev->dev_private;
+   return to_mdp5_kms(to_mdp_kms(priv->kms));
+}
+
+#ifdef CONFIG_MSM_BUS_SCALING
+#include 
+#include 
+#include 
+#define MDP_BUS_VECTOR_ENTRY(ab_val, ib_val)   \
+   {   \
+   .src = MSM_BUS_MASTER_MDP_PORT0,\
+   .dst = MSM_BUS_SLAVE_EBI_CH0,   \
+   .ab = (ab_val), \
+   .ib = (ib_val), \
+   }
+
+static struct msm_bus_vectors mdp_bus_vectors[] = {
+   MDP_BUS_VECTOR_ENTRY(0, 0),
+   MDP_BUS_VECTOR_ENTRY(20, 20),
+};
+static struct msm_bus_paths mdp_bus_usecases[] = { {
+   .num_paths = 1,
+   .vectors = &mdp_bus_vectors[0],
+}, {
+   .num_paths = 1,
+   .vectors = &mdp_bus_vectors[1],
+} };
+static struct msm_bus_scale_pdata mdp_bus_scale_table = {
+   .usecase = mdp_bus_usecases,
+   .num_usecases = ARRAY_SIZE(mdp_bus_usecases),
+   .name = "mdss_mdp",
+};
+
+static void bs_init(struct mdp5_cmd_encoder *mdp5_cmd_enc)
+{
+   mdp5_cmd_enc->bsc = msm_bus_scale_register_client(
+   &mdp_bus_scale_table);
+   DBG("bus scale client: %08x", mdp5_cmd_enc->bsc);
+}
+
+static void bs_fini(struct mdp5_cmd_encoder *mdp5_cmd_enc)
+{
+   if (mdp5_cmd_enc->bsc) {
+   msm_bus_scale_unregister_client(mdp5_cmd_enc->bsc);
+   mdp5_cmd_enc->bsc = 0;
+   }
+}
+
+static void bs_set(struct mdp5_cmd_encoder 

[PATCH v2 3/4] drm/msm: Initial add DSI connector support

2015-03-26 Thread Hai Li
This change adds the DSI connector support in msm drm driver.

v1: Initial change
v2:
- Address comments from Archit + minor clean-ups
- Rebase to not depend on msm_drm_sub_dev change [Rob's comment]

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Kconfig   |   11 +
 drivers/gpu/drm/msm/Makefile  |4 +
 drivers/gpu/drm/msm/dsi/dsi.c |  212 
 drivers/gpu/drm/msm/dsi/dsi.h |  117 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 1992 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  699 
 drivers/gpu/drm/msm/dsi/dsi_phy.c |  352 ++
 drivers/gpu/drm/msm/msm_drv.h |   29 +
 8 files changed, 3416 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
  Compile in support for logging register reads/writes in a format
  that can be parsed by envytools demsm tool.  If enabled, register
  logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+   bool "Enable DSI support in MSM DRM driver"
+   depends on DRM_MSM
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   default y
+   help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \

 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+   dsi/dsi_host.o \
+   dsi/dsi_manager.o \
+   dsi/dsi_phy.o

 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..28d1f95
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi.h"
+
+struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi || !msm_dsi->panel)
+   return NULL;
+
+   return (msm_dsi->panel_flags & MIPI_DSI_MODE_VIDEO) ?
+   msm_dsi->encoders[MSM_DSI_VIDEO_ENCODER_ID] :
+   msm_dsi->encoders[MSM_DSI_CMD_ENCODER_ID];
+}
+
+static void dsi_destroy(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi)
+   return;
+
+   msm_dsi_manager_unregister(msm_dsi);
+   if (msm_dsi->host) {
+   msm_dsi_host_destroy(msm_dsi->host);
+   msm_dsi->host = NULL;
+   }
+
+   platform_set_drvdata(msm_dsi->pdev, NULL);
+}
+
+static struct msm_dsi *dsi_init(struct platform_device *pdev)
+{
+   struct msm_dsi *msm_dsi = NULL;
+   int ret;
+
+   if (!pdev) {
+   dev_err(&pdev->dev, "no dsi device\n");
+   ret = -ENXIO;
+   goto fail;
+   }
+
+   msm_dsi = devm_kzalloc(&pdev->dev, sizeof(*msm_dsi), GFP_KERNEL);
+   if (!msm_dsi) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+   DBG("dsi probed=%p", msm_dsi);
+
+   msm_dsi->pdev = pdev;
+   platform_set_drvdata(pdev, msm_dsi);
+
+   /* Init dsi host */
+   ret = msm_dsi_host_init(msm_dsi);
+   if (ret)
+   goto fail;
+
+   /* Register to dsi manager */
+   ret = msm_dsi_manager_register(msm_dsi);
+   if (ret)
+   goto fail;
+
+   return msm_dsi;
+
+fail:
+   if (msm_dsi)
+   dsi_destroy(msm_dsi);
+
+   return ERR_PTR(ret);
+}
+
+static int dsi_bind(struct device *dev, struct device *master, void *data)
+{
+   struct drm_device *drm = dev_get_drvdata(master);
+   struct msm_drm_private *priv = drm->dev_private;
+   struct platform_device *pdev = to_platform_device(dev);
+   struct msm_dsi *msm_dsi;
+
+   DBG("");
+   msm_dsi = dsi_init(pdev);
+   if (IS_ERR(msm_dsi))
+   return PTR_ERR(msm_dsi);
+
+   priv->dsi[msm_dsi->id] = msm_dsi;
+
+  

[PATCH v2 2/4] drm/msm: Add split display interface

2015-03-26 Thread Hai Li
This change is to add an interface to MDP for connector devices
setting split display information.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/msm_kms.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 3a78cb4..a9f17bd 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -47,6 +47,10 @@ struct msm_kms_funcs {
const struct msm_format *(*get_format)(struct msm_kms *kms, uint32_t 
format);
long (*round_pixclk)(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder);
+   int (*set_split_display)(struct msm_kms *kms,
+   struct drm_encoder *encoder,
+   struct drm_encoder *slave_encoder,
+   bool is_cmd_mode);
/* cleanup: */
void (*preclose)(struct msm_kms *kms, struct drm_file *file);
void (*destroy)(struct msm_kms *kms);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



[PATCH v2 1/4] drm/msm/mdp5: Move *_modeset_init out of construct_encoder function

2015-03-26 Thread Hai Li
This change is to make the content in construct_encoder reflect its
name.
Also, DSI connector may be connected to video mode or command mode
encoder, so that 2 different encoders need to be constructed for DSI.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 89 -
 1 file changed, 54 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index f882019..6d967a8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -163,8 +163,9 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
return 0;
 }

-static int construct_encoder(struct mdp5_kms *mdp5_kms,
-   enum mdp5_intf_type intf_type, int intf_num)
+static struct drm_encoder *construct_encoder(struct mdp5_kms *mdp5_kms,
+   enum mdp5_intf_type intf_type, int intf_num,
+   enum mdp5_intf_mode intf_mode)
 {
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
@@ -172,30 +173,64 @@ static int construct_encoder(struct mdp5_kms *mdp5_kms,
struct mdp5_interface intf = {
.num= intf_num,
.type   = intf_type,
-   .mode   = MDP5_INTF_MODE_NONE,
+   .mode   = intf_mode,
};
-   int ret = 0;

encoder = mdp5_encoder_init(dev, &intf);
if (IS_ERR(encoder)) {
-   ret = PTR_ERR(encoder);
-   dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
-   return ret;
+   dev_err(dev->dev, "failed to construct encoder\n");
+   return encoder;
}

encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
priv->encoders[priv->num_encoders++] = encoder;

-   if (intf_type == INTF_HDMI) {
-   ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
-   if (ret)
-   dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
+   return encoder;
+}
+
+static int modeset_init_intf(struct mdp5_kms *mdp5_kms, int intf_num)
+{
+   struct drm_device *dev = mdp5_kms->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   const struct mdp5_cfg_hw *hw_cfg =
+   mdp5_cfg_get_hw_config(mdp5_kms->cfg);
+   enum mdp5_intf_type intf_type = hw_cfg->intfs[intf_num];
+   struct drm_encoder *encoder;
+   int ret = 0;
+
+   switch (intf_type) {
+   case INTF_DISABLED:
+   break;
+   case INTF_eDP:
+   if (!priv->edp)
+   break;
+
+   encoder = construct_encoder(mdp5_kms, INTF_eDP, intf_num,
+   MDP5_INTF_MODE_NONE);
+   if (IS_ERR(encoder)) {
+   ret = PTR_ERR(encoder);
+   break;
+   }

-   } else if (intf_type == INTF_eDP) {
-   /* Construct bridge/connector for eDP: */
ret = msm_edp_modeset_init(priv->edp, dev, encoder);
-   if (ret)
-   dev_err(dev->dev, "failed to init eDP: %d\n", ret);
+   break;
+   case INTF_HDMI:
+   if (!priv->hdmi)
+   break;
+
+   encoder = construct_encoder(mdp5_kms, INTF_HDMI, intf_num,
+   MDP5_INTF_MODE_NONE);
+   if (IS_ERR(encoder)) {
+   ret = PTR_ERR(encoder);
+   break;
+   }
+
+   ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+   break;
+   default:
+   dev_err(dev->dev, "unknown intf: %d\n", intf_type);
+   ret = -EINVAL;
+   break;
}

return ret;
@@ -261,27 +296,11 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
}

-   /* Construct external display interfaces' encoders: */
+   /* Construct encoders and modeset initialize connector devices
+* for each external display interface.
+*/
for (i = 0; i < ARRAY_SIZE(hw_cfg->intfs); i++) {
-   enum mdp5_intf_type intf_type = hw_cfg->intfs[i];
-
-   switch (intf_type) {
-   case INTF_DISABLED:
-   break;
-   case INTF_eDP:
-   if (priv->edp)
-   ret = construct_encoder(mdp5_kms, INTF_eDP, i);
-   break;
-   case INTF_HDMI:
-   if (priv->hdmi)
-   ret = construct_encoder(mdp5_kms, INTF_HDMI, i);
-   break;
-   default:
-   dev_err(dev->dev, "unknown intf: %d\n", intf_type);
-   ret = -EINVAL;
-   break;
-   }
-
+   ret

[PATCH v2 0/4] drm/msm: Initial add DSI support

2015-03-26 Thread Hai Li
Resending initial MSM DSI patches
DSI is supported by both mdp4 and mdp5. This patch series adds the common DSI
controller driver and also enable it in mdp5.

Hai Li (4):
  drm/msm/mdp5: Move *_modeset_init out of construct_encoder function
  drm/msm: Add split display interface
  drm/msm: Initial add DSI connector support
  drm/msm/mdp5: Enable DSI connector in msm drm driver

 drivers/gpu/drm/msm/Kconfig |   11 +
 drivers/gpu/drm/msm/Makefile|5 +
 drivers/gpu/drm/msm/dsi/dsi.c   |  212 +++
 drivers/gpu/drm/msm/dsi/dsi.h   |  117 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 1992 +++
 drivers/gpu/drm/msm/dsi/dsi_manager.c   |  699 
 drivers/gpu/drm/msm/dsi/dsi_phy.c   |  352 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |4 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c |  343 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|   11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |   43 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  159 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   28 +-
 drivers/gpu/drm/msm/msm_drv.c   |2 +
 drivers/gpu/drm/msm/msm_drv.h   |   29 +
 drivers/gpu/drm/msm/msm_kms.h   |4 +
 16 files changed, 3970 insertions(+), 41 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c

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



Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

2015-03-26 Thread Emil Velikov
Hello Randy

On 26/03/15 16:56, randyf at sibernet.com wrote:
>>
>> Was honestly hoping that patch #1 is not required as:
>> - Getting the drm.h header in sync with the kernel will be annoying.
> 
>   Indeed.
> 
>   I have a version of drm.h that works with Solaris and *should* still
> work with all other consumers, but as I still have a ways to get fully
> to speed, am hesitant to suggest a patch (are there other issues I have
> yet to discover).
> 
Afaict the current Patch #1 will work with non-sun consumers.
Considering that the header(s) are currently out of sync (rather badly
imho), and the legacy note below would be nice if we can avoid the change.

Sometimes dri-devel can be a bit slow, so I would suggest that you post
finding/patches earlier rather than later.

>> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
>> cruft for which, I would like to think, there are no more users.
>>
>> Obviously the latter can be confirmed by Randy and friends.
> 
>   I'm somewhat confused by this statement, as I still see the use of
> struct drm_map, as is it's usage in the Solaris ports of drm.  Am I
> missing something (like I said, I still have a ways to go to get to any
> decent level of contribution)?
> 
Can you relate Solaris ports of drm to the linux one in a sentence ? Or
if there is a public repo somewhere that would be great.

Guessing that "legacy" is the keyword here - it refers to old drm
drivers that do user mode-setting - UMS, amongst other nasty stuff.
Based on the latest kernel sources the ioctls (and the struct) are
considered as legacy, that plus the lack of any users (very quick grep)
seems rather conclusive.

If you guys are still using legacy drm drivers (for whatever reason)
that would be rather unfortunate. Otherwise you should be able to kill
off the remaining users of struct drm_map/drmMapBufs/drmRmMap.


Cheers,
Emil



[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89746

--- Comment #13 from giuseppe  ---
How do I apply the patch? Can anyone help me indicating the command pls?

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


[PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio

2015-03-26 Thread Mark Brown
On Fri, Mar 27, 2015 at 09:16:17AM +0800, yakir wrote:
> On 2015年03月27日 02:16, Mark Brown wrote:

> >>+free_cpu_of_node:
> >>+   hdmi_audio_dai.cpu_of_node = NULL;
> >>+   hdmi_audio_dai.platform_of_node = NULL;
> >>+free_priv_data:
> >>+   snd_soc_card_set_drvdata(card, NULL);
> >>+   platform_set_drvdata(pdev, NULL);
> >>+   card->dev = NULL;

> >If any of these assignments is doing anything there's a problem with the
> >code.


> Yes, when probe failed, program will goto this code.

You're missing the point, these don't do anything useful.

> >>+{
> >>+   struct snd_soc_card *card = platform_get_drvdata(pdev);
> >>+
> >>+   snd_soc_unregister_card(card);

> >devm_snd_soc_register_card() and you can remove this function entirely.

> do you mean that when I take devm_snd_soc_register_card() to register card,
> then I do not need unregister card any more(destroy with device) ?

Yes, that is the whole point of the devm_ APIs.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/6af5bff2/attachment.sig>


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread Michael S. Tsirkin
On Thu, Mar 26, 2015 at 04:07:16PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > I don't know. This seems exactly like the kind of thing
> > we had in mind when we added the virtio pci capability.
> > For example, we have text in spec that requires drivers
> > to skip unknown capabilities.
> > 
> > And yes, if bios pokes at a specific bar then we do
> > need to list this info in the virtio spec so this makes
> > it an issue that is virtio related.
> 
> Hmm, virtio-vga is a two-in-one device basically.  When virtio is
> enabled it behaves like virtio-gpu-pci, otherwise it behaves very
> simliar to stdvga.  So you need to know nothing about virtio to handle
> the vga side, and I want keep it that way.
> 
> When no vga compatibility is needed there always is the option to just
> use virtio-gpu-pci instead.
> 
> > Yes, it's not about what we put there now. It's about being able
> > to move things about in the future without breaking guests.
> 
> We don't have that today for stdvga, and I still fail to see what this
> buys us.
> 
> 
> Completely different thing crossing my mind:  I think we can make
> virtio-vga fully compatible with stdvga.  stdvga has two bars, memory
> (#0) and mmio (#2).  We can make the mmio bar larger and place all the
> virtio regions there.
> 

Full compatibility with some standard sounds like a better motivation,
yes.

> 
> I think in any case I'll go split off the vga compatibility bits to a
> different patch (and possible a separate patch series).
> 
> cheers,
>   Gerd

Will you still need me to change core to claim specific memory only?


-- 
MST


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread One Thousand Gnomes
> It's not about virtio at all.  It's about vga compatibility, so we have
> a simple framebuffer as boot display.  Only used when virtio is *not*
> enabled.

VGA can be a separate device altogether.

In fact there were *real* PCI graphics cards that did this and had a
register than flipped the output source over.

Alan


[Intel-gfx] [git pull] drm fixes

2015-03-26 Thread Xi Ruoyao


On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
> On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
I hide the patch since it has been managled by Thunderbird.
(BTW, who can tell me how to stop Thunderbird to replace Tabs to spaces?)
>> which is a mash-up of:
>>
>> "drm/i915: Fix atomic state when reusing the firmware fb"
>>
>> and
>>
>> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>>
>> which you just sent out.
>>
>> I think that covers everything.
>>
>> josh
> I've got an HDMI device from the laboratory. I'll help to test the 
> solution.
>
I confirm that after applying those 3 patches, my machine boots fine mutiple
times WITH OR WITHOUT HDMI plugged in and there is no WARNINGs about
drm/i915 in kernel log. So I think these patches have successfully 
solved the
problem, although maybe I am the one who makes some mistakes again..

-- 
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China



[Bug 89374] Firefox smooth scrolling isn't smooth

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89374

--- Comment #11 from sunweb at hotmail.ru ---
(In reply to Michel Dänzer from comment #10)
> Not using Windows or smooth scrolling myself, I'm just not sure how smooth
> it's supposed to be. Don't worry, I'm not arguing there's no problem, just
> making suggestions that might improve your experience.

I've tried it in a notebook that has both intel and amd graphics. On intel
smooth scrolling even at heavy sites works really good.
A bit offtopic. How do i use amd gpu in such notebook and are you planing to
add some gui to switch between gpus and choose what programms to run with which
gpu?

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


[Intel-gfx] [PATCH] drm/i915/skl: fix semicolon.cocci warnings

2015-03-26 Thread Daniel Vetter
On Thu, Mar 26, 2015 at 10:30:21PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/intel_pm.c:2913:4-5: Unneeded semicolon
> 
> 
>  Removes unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> CC: Tvrtko Ursulin 
> Signed-off-by: Fengguang Wu 

Oops, somehow didn't see your patch at first. Applied this one now instead
of mine.
-Daniel

> ---
> 
>  intel_pm.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2910,7 +2910,7 @@ static bool skl_compute_plane_wm(const s
>   break;
>   case 8:
>   WARN(1, "Unsupported pixel depth for rotation");
> - };
> + }
>   }
>   y_tile_minimum = plane_blocks_per_line * min_scanlines;
>   selected_result = max(method2, y_tile_minimum);
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[PATCH] xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic

2015-03-26 Thread Emil Velikov
On 26/03/15 15:38, Daniel Kurtz wrote:
> Hi Emil,
> 
> On Thu, Mar 26, 2015 at 11:12 PM, Emil Velikov  
> wrote:
>>
>> Hi Daniel,
>> On 25/03/15 01:01, Daniel Kurtz wrote:
>>> Unfortunately, there are some users of libdrm installed headers that like
>>> to be built with -std=c89 -pedantic, which does not like "inline".
>>>
>>> However, __inline works.
>>>
>>> Signed-off-by: Daniel Kurtz 
>>
>>> ---
>>>  xf86drmMode.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/xf86drmMode.h b/xf86drmMode.h
>>> index 856a6bb..2d30184 100644
>>> --- a/xf86drmMode.h
>>> +++ b/xf86drmMode.h
>>> @@ -240,7 +240,7 @@ typedef struct _drmModeProperty {
>>>   uint32_t *blob_ids; /* store the blob IDs */
>>>  } drmModePropertyRes, *drmModePropertyPtr;
>>>
>>> -static inline int drm_property_type_is(drmModePropertyPtr property,
>>> +static __inline int drm_property_type_is(drmModePropertyPtr property,
>>
>> Can you share the name of those users ?
>>
>> From a quick look clang and gcc are ok with this change, although some
>> versions of the Sun compiler are not. Considering that most programs try
>> to use c99 and later, might I suggest that you add a trivial wrapper in
>> your program ? Something along the lines of
>>
>> #ifndef inline
>> #define inline __inline
>> #endif
> 
> It isn't a program, its a third party EGL/GLES driver, so, no I can't
> really do this easily.
> 
I see... due to various agreements you're not allowed to make any
changes. Be that to the code or the build (-Dinline...).

> Alternatively can we:
>  (1) move the wrapper to xf86drmMode.h itself, or
>  (2) move this inline helper function out of xf86drmMode.h and into
> the two libdrm tests that use it (or a shared test helper .h [0])
>  (3) remove the inline and make drm_property_type_is a non-inline
> function in xf86drmMode.c
> 
> [0] I think Thierry already has a patch set that rearranges the tests
> to use some shared headers.  Perhaps this will work well once his set
> lands.
> 
Fwiw I would opt for 1 or 3 (leaning towards 1), as 2 might lead to:
 - Everyone coming up with their own "helper", or
 - Ignoring DRM_MODE_PROP_EXTENDED_TYPE checking
drmModePropertyPtr::flags, thus causing all sorts of chaos.


Randy, Niveditha, Stuart,

Does the compiler(s) used to build libdrm and friends support __inline ?

Thanks,
Emil

P.S. [0] Seems to be missing but I do recall the series :)



[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89746

--- Comment #12 from Ming-Wei Shih  ---
My bad, the patch in #7 fixed the regression for me.

I was having issues earlier because an other user had genymotion running and
locked on the same machine, genymotion sometimes has issues to find the correct
session and times out when there are multiple users (uid) using it.

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


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread Gerd Hoffmann
  Hi,

> I don't know. This seems exactly like the kind of thing
> we had in mind when we added the virtio pci capability.
> For example, we have text in spec that requires drivers
> to skip unknown capabilities.
> 
> And yes, if bios pokes at a specific bar then we do
> need to list this info in the virtio spec so this makes
> it an issue that is virtio related.

Hmm, virtio-vga is a two-in-one device basically.  When virtio is
enabled it behaves like virtio-gpu-pci, otherwise it behaves very
simliar to stdvga.  So you need to know nothing about virtio to handle
the vga side, and I want keep it that way.

When no vga compatibility is needed there always is the option to just
use virtio-gpu-pci instead.

> Yes, it's not about what we put there now. It's about being able
> to move things about in the future without breaking guests.

We don't have that today for stdvga, and I still fail to see what this
buys us.


Completely different thing crossing my mind:  I think we can make
virtio-vga fully compatible with stdvga.  stdvga has two bars, memory
(#0) and mmio (#2).  We can make the mmio bar larger and place all the
virtio regions there.


I think in any case I'll go split off the vga compatibility bits to a
different patch (and possible a separate patch series).

cheers,
  Gerd




[Bug 89780] Vertex drawing error on Civilization Beyond Earth

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89780

Jan Vesely  changed:

   What|Removed |Added

 Attachment #114649|text/plain  |image/jpeg
  mime type||

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


[Bug 89780] Vertex drawing error on Civilization Beyond Earth

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89780

Peter Asplund  changed:

   What|Removed |Added

URL||http://steamcommunity.com/s
   ||haredfiles/filedetails/?id=
   ||378154313
   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

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


[Bug 89780] Vertex drawing error on Civilization Beyond Earth

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89780

--- Comment #1 from Peter Asplund  ---
Attachment is jpg

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


[Bug 89780] Vertex drawing error on Civilization Beyond Earth

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89780

Bug ID: 89780
   Summary: Vertex drawing error on Civilization Beyond Earth
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: peterasplund at gentoo.se
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 114649
  --> https://bugs.freedesktop.org/attachment.cgi?id=114649&action=edit
Screenshot of the issue

It seems like there is something wrong when vertices are drawn in Civilization
Beyond Earth on RadeonSI drivers. I am running with a Radeon R9 290 card.

It looks like all models have one vertex in (0,0,0) for some reason.

I know that Beyond Earth officially requires AMD Catalyst drivers, but I wanted
to report the bug just in case. Otherwise the game ran great (except terrain
rendering bug that has also been reported).

Screenshot attached and can also be found here:
http://steamcommunity.com/sharedfiles/filedetails/?id=378154313

Mesa 10.4
3.18 kernel
LLVM 3.5
Radeon 290

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


Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

2015-03-26 Thread Emil Velikov
On 23/03/15 01:46, Alan Coopersmith wrote:
> On 03/ 9/15 05:37 AM, Emil Velikov wrote:
>> The former does not imply the latter and vice-versa. One such example is
>> the Sun compiler.
>>
>> Cc: Alan Coopersmith 
>> Cc: Thierry Reding 
>> Signed-off-by: Emil Velikov 
>> ---
>>
>> Hi Alan,
>> Can you please take a look it this series covers the symbol visibility
>> issues mentioned earlier ? In theory it should work like a charm but I
>> cannot really test it :-\
> 
> Patch 1 of 2 breaks configure on Solaris - I get:
> 
> checking for VALGRIND... no
> checking whether cc -xc99=%all supports __attribute__((visibility))...
> ./configure[13393]: set does not quote correctly, so add quotes:
> double-quote^J  # substitution turns \\ into \, and sed turns \ into
> \.^J  sed -n ^I"s//\\/g;^J^I 
> s/^\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\)=\(.*\)/\1=2/p"^J  ;;
> #(^J*)^J  # : not found [No such file or directory]
> ./configure[13393]: {\1+set}: bad substitution
> ./configure[13992]: : cannot open
> ./configure[14000]: : cannot open
> ./configure[14032]: : cannot open
> ./configure[14051]: : cannot open
> ./configure[14128]: : cannot open
> ./configure[14139]: : cannot open
> ./configure[14150]: : cannot open
> ./configure[14435]: : cannot open
> ./configure[14563]: : cannot open
> ./configure[14603]: : cannot open
> ./configure[14610]: : cannot open
> ./configure[14639]: : cannot open
> ./configure[14671]: : cannot open
> ./configure[14740]: : cannot open
> ./configure[14744]: : cannot open
> ./configure[14778]: : cannot open
> ./configure[14928]: : cannot open
> ./configure[14948]: : cannot open
> ./configure[14962]: : cannot open
> ./configure[14966]: : cannot open
> configure: error: write failure creating
> It also generated new autoconf warnings generating the configure script:
> 
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> autoreconf: running:
> /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoconf --force
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> autoreconf: running:
> /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoheader
> --force
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> autoreconf: running: automake --add-missing --copy --force-missing
> configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
> configure.ac:422: the top level
> 
> Both seem to have been caused by a misplaced close paren/brace pair and
> are fixed by:
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports
> __attribute__((visibility))])
> AC_LINK_IFELSE([AC_LANG_PROGRAM([
> int foo_default( void ) __attribute__((visibility("default")));
> int foo_hidden( void ) __attribute__((visibility("hidden")));
> -], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]),
> AC_MSG_RESULT([no])]);
> +])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])],
> AC_MSG_RESULT([no]));
> 
> if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
> AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports
> __attribute__((visibility))])
> 
> (Gotta love autoconf and the mysteries of proper [] placements.)
> 
Playing around with [] is always fun. Thanks for the fix.

> After that I can build on Solaris with patch #1 applied, but patch #2
> then breaks
> due to Solaris Studio 12.4 compilers being more pedantic about
> prototypes in headers
> having the external visibility declarations too - lots of errors of the
> form:
> 
> "intel_bufmgr.c", line 60: redeclaration must have the same or more
> restr

[PATCH v2 1/5] tests/exynos: add fimg2d performance analysis

2015-03-26 Thread Emil Velikov
On 25/03/15 16:48, Tobias Jakobi wrote:
> Currently only fast solid color clear performance is measured.
> A large buffer is allocated and solid color clear operations
> are executed on it with randomly chosen properties (position
> and size of the region, clear color). Execution time is
> measured and output together with the amount of pixels
> processed.
> 
> The 'simple' variant only executes one G2D command buffer at
> a time, while the 'multi' variant executes multiple ones. This
> can be used to measure setup/exec overhead.
> 
> The test also serves a stability check. If clocks/voltages are
> too high or low respectively, the test quickly reveals this.
> 
> v2: Add GPLv2 header, argument handling and documentation.
> Tool is only installed when requested.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  tests/exynos/Makefile.am  |  19 ++-
>  tests/exynos/exynos_fimg2d_perf.c | 320 
> ++
>  2 files changed, 337 insertions(+), 2 deletions(-)
>  create mode 100644 tests/exynos/exynos_fimg2d_perf.c
> 
> diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
> index b21d016..e82d199 100644
> --- a/tests/exynos/Makefile.am
> +++ b/tests/exynos/Makefile.am
> @@ -5,16 +5,31 @@ AM_CFLAGS = \
>   -I $(top_srcdir)/exynos \
>   -I $(top_srcdir)
>  
> +bin_PROGRAMS =
> +noinst_PROGRAMS =
> +
>  if HAVE_LIBKMS
>  if HAVE_INSTALL_TESTS
> -bin_PROGRAMS = \
> +bin_PROGRAMS += \
>   exynos_fimg2d_test
>  else
> -noinst_PROGRAMS = \
> +noinst_PROGRAMS += \
>   exynos_fimg2d_test
>  endif
>  endif
>  
> +if HAVE_INSTALL_TESTS
> +bin_PROGRAMS += \
> + exynos_fimg2d_perf
> +else
> +noinst_PROGRAMS += \
> + exynos_fimg2d_perf
> +endif
> +
One can simplify this as below, although I will not worry too much about
it :) That aside would be nice to hear some feedback from the Exynos and
the old school libdrm devs on the core changes.


if HAVE_LIBKMS
FOO = \
exynos_fimg2d_test
endif

if HAVE_INSTALL_TESTS
bin_PROGRAMS = \
$(FOO) \
exynos_fimg2d_perf
else
noinst_PROGRAMS = \
$(FOO) \
exynos_fimg2d_perf
endif


-Emil



[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89713

--- Comment #6 from Iaroslav Andrusyak  ---
No, looks like there is no difference with the patch or not, sometimes more
time for close the game, sometimes less.
R600_DEBUG=noinvalrange,nocpdma helps to increase game time without failure
This is what happens during GPU lockup
http://savepic.su/5493290.png

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


[PATCH 1/5] tests/exynos: add fimg2d performance analysis

2015-03-26 Thread Emil Velikov
On 25/03/15 18:27, Tobias Jakobi wrote:
> Hello,
> 
> the new version should fix most of the mentioned issues.
> 
> Tobias Jakobi wrote:
>>> As a general note I would recommend keeping statements on separate lines
>>> (none of if (foo) far()) as it makes debugging easier.
>> OK, changing this.
> Except for this, I didn't change it since I don't see the point. In fact
> I think that splitting the few occurrences makes the code less readable.
> 
Beauty is in the eye of the beholder.

> I haven't worked with getopt before, so I gave it a try and made all
> these hardcoded parameters configurable.
> 
Nice :-)

Cheers,
Emil


[PATCH libdrm 0/9] Rework remaining tests

2015-03-26 Thread Emil Velikov
On 24/03/15 23:20, Jan Vesely wrote:
> On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
>> This series covers
>>  - Remove the hackish "include xf86drmfoo.c" from dristat
>>  - Extract the remaining two xf86drmfoo.c tests to standalone ones
>>  - beat them into shape, and
>>  - wire them up to make check.
> 
> I finished going through the series. Feel free to ignore the internal
> header suggestions, I don;t think the risk of desynchronizing structures
> in test and implementation is real since few ppl will touch it anyway.
> 
> drmHash test looks weird after cleanup.
> other than that looks good
> 
Thanks I'll update the series (incorporating all of your comments), drop
patch 1 for now, and send it out in a bit.

-Emil



[PATCH] xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic

2015-03-26 Thread Emil Velikov
Hi Daniel,
On 25/03/15 01:01, Daniel Kurtz wrote:
> Unfortunately, there are some users of libdrm installed headers that like
> to be built with -std=c89 -pedantic, which does not like "inline".
> 
> However, __inline works.
> 
> Signed-off-by: Daniel Kurtz 

> ---
>  xf86drmMode.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index 856a6bb..2d30184 100644
> --- a/xf86drmMode.h
> +++ b/xf86drmMode.h
> @@ -240,7 +240,7 @@ typedef struct _drmModeProperty {
>   uint32_t *blob_ids; /* store the blob IDs */
>  } drmModePropertyRes, *drmModePropertyPtr;
>  
> -static inline int drm_property_type_is(drmModePropertyPtr property,
> +static __inline int drm_property_type_is(drmModePropertyPtr property,

Can you share the name of those users ?

>From a quick look clang and gcc are ok with this change, although some
versions of the Sun compiler are not. Considering that most programs try
to use c99 and later, might I suggest that you add a trivial wrapper in
your program ? Something along the lines of

#ifndef inline
#define inline __inline
#endif


-Emil



[PATCH libdrm 1/9] tests/dristat: don't include C files

2015-03-26 Thread Emil Velikov
On 23/03/15 22:10, Jan Vesely wrote:
> On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
>> Remove the hack of including C files, by reworking the only requirement
>> drmOpenMinor() to an open(buf...). After all we do know the exact name
>> of the device we're going to open, so might as well use it. Replace
>> hard-coded 16 with DRM_MAX_MINOR while we're here.
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>  tests/dristat.c | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/tests/dristat.c b/tests/dristat.c
>> index cca4b03..cc23e16 100644
>> --- a/tests/dristat.c
>> +++ b/tests/dristat.c
>> @@ -31,13 +31,14 @@
>>  # include 
>>  #endif
>>  
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include "xf86drm.h"
>> -#include "xf86drmRandom.c"
>> -#include "xf86drmHash.c"
>> -#include "xf86drm.c"
>>  
>>  #define DRM_VERSION 0x0001
>>  #define DRM_MEMORY  0x0002
>> @@ -267,9 +268,9 @@ int main(int argc, char **argv)
>>  return 1;
>>  }
>>  
>> -for (i = 0; i < 16; i++) if (!minor || i == minor) {
>> +for (i = 0; i < DRM_MAX_MINOR; i++) if (!minor || i == minor) {
>>  sprintf(buf, DRM_DEV_NAME, DRM_DIR_NAME, i);
>> -fd = drmOpenMinor(i, 1, DRM_NODE_PRIMARY);
>> +fd = open(buf, O_RDWR, 0);
> 
> What about the "create" (second) argument? The original code creates the
> node if it does not exist (on non-UDEV systems), or waits some time for
> udev to create it.
> Not sure how this is relevant for the test.
> 
Hmm brain triggered this as "create = 0", as I was going through. Fwiw I
would opt for nuking this custom hack, and stick with open().

If one needs to wait for udev or manually create the nod then they have
bigger ship to fry. All of that should be resolved before anyone has the
change to run the program.

Let's give it some time for people to voice their opinions on the topic.
Could be that something more elaborate is happing if create is set.


-Emil



[PATCH libdrm v3 1/3] drmSL: Fix neighbor lookup

2015-03-26 Thread Emil Velikov
On 24/03/15 23:16, Jan Vesely wrote:
> Commit e4a519635f75bde38aeb5b09f2ff4efbf73453e9:
> Tidy up compile warnings by cleaning up types.
> 
> removed call to SLLocate which gutted the function of all functionality.
> This patch restores the original behavior, with an additional fix
> that zeros the update array in case SLLocate bails early.
> 
> v2: zero the update array instead of checking the return value.
> SLLocate returns NULL both on failure and if the element is greater
> than everything in the list
> v3: Improve commit message
> 
> Signed-off-by: Jan Vesely 
> Acked-by: Emil Velikov 
> ---
> sorry for spamming, just realized it might be a good idea co CC the original
> author and committer.
> 
> This was broken since 2.4.18 (2010). I guess it's safe to say that nobody
> uses it. What are the policies on removing parts of API?
> 
Either nobody uses it or nobody which uses it cases enough to report/fix
it. Either way I think that people prefer to be cautious and do API
cleanups alongside a major bump of the library.

-Emil



[PATCH libdrm 2/3] tests/drmsl: Extract tests out of xf86drmSL.c

2015-03-26 Thread Emil Velikov
On 24/03/15 23:06, Jan Vesely wrote:
> v2: merge tests creation and xf86drmSL cleanup
> rename tests/drmsltest -> tests/drmsl
> move the test out of libudev test block
> 
> Signed-off-by: Jan Vesely 
> ---
> 
> Hi Emil,
> I know you send your R-b on the earlier version, but I thought the changes
> were big enough to send v2. I modeled it after you test splitting series.
> 
> jan
> 
>  .gitignore|   1 +
>  tests/Makefile.am |   5 +-
>  tests/drmsl.c | 172 
> ++
>  xf86drmSL.c   | 172 
> ++
>  4 files changed, 183 insertions(+), 167 deletions(-)
>  create mode 100644 tests/drmsl.c
> 
> diff --git a/.gitignore b/.gitignore
> index 06cc928..cb7128d 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -74,6 +74,7 @@ tdfx.kld
>  via.kld
>  tests/auth
>  tests/dristat
> +tests/drmsl
>  tests/drmstat
>  tests/getclient
>  tests/getstats
Hmm this reminds me that I missed out updating the .gitignore with my
series.

> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 10f54e3..ad70314 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -35,6 +35,9 @@ if HAVE_NOUVEAU
>  SUBDIRS += nouveau
>  endif
>  
> +TESTS = \
> + drmsl
> +
>  if HAVE_LIBUDEV
>  
>  check_LTLIBRARIES = libdrmtest.la
> @@ -52,7 +55,7 @@ XFAIL_TESTS =   \
>   auth\
>   lock
>  
> -TESTS =  \
> +TESTS += \
>   openclose   \
>   getversion  \
>   getclient   \
You will need the following hunk, otherwise drmsl will not end up in the
check target. Although when I think about it there isn't much value in
running this at make check time. I'll leave the decision up-to you.

--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -61,6 +61,7 @@ TESTS =   \
updatedraw  \
name_from_fd

+endif
+
 check_PROGRAMS += $(TESTS)

-endif


As before haven't explicitly checked the moved code so

Acked-by: Emil Velikov 

Thanks
Emil


[PATCH] drm: Exynos: Respect framebuffer pitch for FIMD/Mixer

2015-03-26 Thread Daniel Stone
Hi Inki,

On Thu, 26 Mar, 2015 at 2:32 PM, Inki Dae  wrote:
> Applied.

Thanks very much.

> Could you use right prefix of the subject like below when you post 
> patch?
> 
> 'drm/exynos: ...', not 'drm: Exynos: ...'
> 
> Your email will be filtered from my mailbox if you don't use the right
> prefix so I couldn't check and take care of your patch.

Ah, I didn't realise this. Maybe it could be good to not filter if the 
patch is also directly addressed/CCed to you, rather than a list? 
Gustavo Padovan is following this convention and I also will in future, 
but I guess it might lead to some patches being dropped from casual 
contributors if they don't know this.

Cheers,
Daniel

> 
> Thanks,
> Inki Dae
> 
> On 2015년 03월 24일 17:57, Javier Martinez Canillas wrote:
>>  Hello Inki,
>> 
>>  On Tue, Mar 17, 2015 at 2:24 PM, Daniel Stone 
>>  wrote:
>>>  When performing a modeset, use the framebuffer pitch value to set 
>>> FIMD
>>>  IMG_SIZE and Mixer SPAN registers. These are both defined as pitch 
>>> - the
>>>  distance between contiguous lines (bytes for FIMD, pixels for 
>>> mixer).
>>> 
>>>  Fixes display on Snow (1366x768).
>>> 
>>>  Signed-off-by: Daniel Stone 
>>>  Tested-by: Javier Martinez Canillas 
>>> 
>> 
>>  Any comments on this patch? It would be great to pick this sooner
>>  rather than later since it fixes (at least) display output on Snow 
>> and
>>  HDMI output on Peach Pit/Pi.
>> 
>>  Best regards,
>>  Javier
>> 
> 
> 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/63a3243c/attachment.html>


[git pull] drm urgent fix

2015-03-26 Thread Jani Nikula
On Thu, 26 Mar 2015, Daniel Vetter  wrote:
> On Thu, Mar 26, 2015 at 4:29 AM, Dave Airlie  wrote:
>> I've pushed a drm-fixes-staging branch that backport's Daniel's
>> drm-next fix from 9 hours ago,
>>
>> However it isn't tested yet, so if you want to give it a whirl grab it.
>>
>> Hopefully when Daniel comes on line he can provide assurance that my
>> fix is a correct backport.
>
> Your missing the backport of
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau 
> Date:   Thu Feb 5 19:24:25 2015 +
>
> drm/i915: Fix atomic state when reusing the firmware fb
>
> My manual backport is here
>
> http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg854137.html
>
> The backport of the other patch you have in -staging looks fine.

The drm-intel-fixes pull request I just sent [1] covers both of
these. It's on top of drm-fixes, i.e. superseeds -staging.

BR,
Jani.

[1] http://mid.gmane.org/87egocrmyc.fsf at intel.com


-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

2015-03-26 Thread Jani Nikula
On Wed, 25 Mar 2015, Daniel Vetter  wrote:
> This is a very similar bug in the load detect code fixed in
>
> commit 9128b040eb774e04bc23777b005ace2b66ab2a85
> Author: Daniel Vetter 
> Date:   Tue Mar 3 17:31:21 2015 +0100
>
> drm/i915: Fix modeset state confusion in the load detect code
>
> But this time around it was the initial fb code that forgot to update
> the plane->crtc pointer. Otherwise it's the exact same bug, with the
> exact same restrains (any set_config call/ioctl that doesn't disable
> the pipe papers over the bug for free, so fairly hard to hit in normal
> testing). So if you want the full explanation just go read that one
> over there - it's rather long ...
>
> Cc: Matt Roper 
> Cc: Linus Torvalds 
> Cc: Chris Wilson 
> Cc: Josh Boyer 
> Cc: Jani Nikula 
> Signed-off-by: Daniel Vetter 
> ---
> This is the version for -next. The one for -fixes just needs an
> s/primary/intel_crtc->base.primary/ and some fudge in the diff. I just
> want to apply this in both trees since with all the cherry-picking the
> conflicts are fun already and with this patch in both places we can
> just go with the code in -next.

I've also picked this up from -next to drm-intel-fixes.

BR,
Jani.


>
> Cheers, Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ceb2e61b4c91..cb508542c6ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>  
>   primary->fb = &plane_config->fb->base;
>   primary->state->crtc = &intel_crtc->base;
> + primary->crtc = &intel_crtc->base;
>   update_state_fb(primary);
>  
>   return;
> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>   drm_framebuffer_reference(c->primary->fb);
>   primary->fb = c->primary->fb;
>   primary->state->crtc = &intel_crtc->base;
> + primary->crtc = &intel_crtc->base;
>   update_state_fb(intel_crtc->base.primary);
>   obj->frontbuffer_bits |= 
> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>   break;
> -- 
> 2.1.4
>

-- 
Jani Nikula, Intel Open Source Technology Center


[Intel-gfx] [git pull] drm fixes

2015-03-26 Thread Jani Nikula
On Wed, 25 Mar 2015, Josh Boyer  wrote:
> On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter  wrote:
>> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>>> > I'll try that a bit later today.  Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to the fb
>>> > update) into the patch above and kicked off a build.  The theory is
>>> > that we're picking up a bunch of other changes right in that range of
>>> > commits, why not try one more.  I'll let you know if that fixes
>>> > anything.  Otherwise, I'll try building drm-intel-nightly and/or
>>> > linux-next after that.
>>>
>>> The drm-intel-nightly build finished first.  It boots without HDMI
>>> plugged in, but it has pretty much the same splats as the previous
>>> kernel.  Confused.  Full log here:
>>>
>>> https://jwboyer.fedorapeople.org/pub/intel-nightly.txt
>>>
>>> I don't have much hope for my other build.
>>
>> Yeah that's at least good news for the theory I've been cooking meanwhile.
>> Can you try the below diff (on top of next/nightly)? For the current
>> cherry-pick pile on top of 4.0-rc you'd need to prepend intel_crtc->base.
>> to primary->...
>>
>> Thanks, Daniel
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index ceb2e61b4c91..cb508542c6ab 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>>
>> primary->fb = &plane_config->fb->base;
>> primary->state->crtc = &intel_crtc->base;
>> +   primary->crtc = &intel_crtc->base;
>> update_state_fb(primary);
>>
>> return;
>> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>> drm_framebuffer_reference(c->primary->fb);
>> primary->fb = c->primary->fb;
>> primary->state->crtc = &intel_crtc->base;
>> +   primary->crtc = &intel_crtc->base;
>> update_state_fb(intel_crtc->base.primary);
>> obj->frontbuffer_bits |= 
>> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>> break;
>
> Hey, that seems to do the trick on the NUC machine.  Boots without
> HDMI connected and there are no backtraces.  Nice!

I've picked this [1] up for drm-intel-fixes as well. Thanks for the
testing.

BR,
Jani.


[1] http://mid.gmane.org/1427304638-7897-1-git-send-email-daniel.vetter at 
ffwll.ch



-- 
Jani Nikula, Intel Open Source Technology Center


[Intel-gfx] [git pull] drm fixes

2015-03-26 Thread Jani Nikula
On Wed, 25 Mar 2015, Daniel Vetter  wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless.  I still see the backtrace below on both
>> the NUC and the macbook.  I have a copy of it with drm.debug=0xff from
>> the NUC here:
>> 
>> https://jwboyer.fedorapeople.org/pub/nuc-drm-debug-ff-with-fixes.txt
>> 
>> Getting better at least :).
>
> On top of what you currently have please also cherry-pick
>
> commit fb9981aa675eb7b398849915364916fd98833cfa
> Author: Damien Lespiau 
> Date:   Thu Feb 5 19:24:25 2015 +
>
> drm/i915: Fix atomic state when reusing the firmware fb
>
> from -next. Let's hope this terminates eventually ;-)

For posterity, I've picked this up for drm-intel-fixes. Thanks for all
the testing.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center


[PULL] drm-intel-fixes

2015-03-26 Thread Jani Nikula

Hi Dave -

This should cover the final warnings in -rc5 with two more backports
from our development branch (drm-intel-next-queued). They're the ones
from Daniel and Damien, with references to the reports.

This is on top of drm-fixes because of the dependency on the two earlier
fixes not yet in Linus' tree.

There's an additional regression fix from Chris.


BR,
Jani.


The following changes since commit 59a58cb34d3fe73e6c899cc5d9a87428ca662925:

  drm/i915: Don't try to reference the fb in get_initial_plane_config() 
(2015-03-25 10:01:46 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-03-26

for you to fetch changes up to 5f407751b0ca9bd876fe8f15ff28153661c6ba0a:

  drm/i915: Fixup legacy plane->crtc link for initial fb config (2015-03-26 
13:39:04 +0200)


Chris Wilson (1):
  drm/i915: Keep ring->active_list and ring->requests_list consistent

Damien Lespiau (1):
  drm/i915: Fix atomic state when reusing the firmware fb

Daniel Vetter (1):
  drm/i915: Fixup legacy plane->crtc link for initial fb config

 drivers/gpu/drm/i915/i915_gem.c  | 38 
 drivers/gpu/drm/i915/intel_display.c | 13 ++--
 2 files changed, 32 insertions(+), 19 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH v3 4/4] arm/dts/ls1021a: Add a TFT LCD panel dts node for DCU

2015-03-26 Thread Jianwei Wang
Add a required display-timings node for the TFT LCD panel
the TFT LCD panel is WQVGA "480x272", and the bpp is 24.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..4780b11 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -58,6 +58,32 @@
};
 };

+&dcu {
+   display = <&display>;
+   status = "okay";
+
+   display: display at 0 {
+   bits-per-pixel = <24>;
+
+   display-timings {
+   native-mode = <&timing0>;
+   timing0: nl4827hc19 {
+   clock-frequency = <1087>;
+   hactive = <480>;
+   vactive = <272>;
+   hback-porch = <2>;
+   hfront-porch = <2>;
+   vback-porch = <2>;
+   vfront-porch = <2>;
+   hsync-len = <41>;
+   vsync-len = <4>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   };
+   };
+   };
+};
+
 &dspi1 {
bus-num = <0>;
status = "okay";
-- 
2.1.0.27.g96db324



[PATCH v3 3/4] arm/dts/ls1021a: Add DCU dts node

2015-03-26 Thread Jianwei Wang
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..6d6e3e2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
 <&platform_clk 1>;
};

+   dcu: dcu at 2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   interrupts = ;
+   clocks = <&platform_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   status = "disabled";
+   };
+
mdio0: mdio at 2d24000 {
compatible = "gianfar";
device_type = "mdio";
-- 
2.1.0.27.g96db324



[PATCH v3 2/4] arm/layerscape/ls1021a: DCU pixel clock control

2015-03-26 Thread Jianwei Wang
Enable DCU pixel clock when platform devices initinalizing and
provide enable and disable pixel clock functions for drm driver

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/mach-imx/mach-ls1021a.c | 36 
 include/linux/fsl/dcu.h  | 22 ++
 2 files changed, 58 insertions(+)
 create mode 100644 include/linux/fsl/dcu.h

diff --git a/arch/arm/mach-imx/mach-ls1021a.c b/arch/arm/mach-imx/mach-ls1021a.c
index b89c858..4fb346d 100644
--- a/arch/arm/mach-imx/mach-ls1021a.c
+++ b/arch/arm/mach-imx/mach-ls1021a.c
@@ -8,9 +8,44 @@
  */

 #include 
+#include 
+#include 
+#include 
+#include 

 #include "common.h"

+void dcu_pixclk_disable(void)
+{
+   struct regmap *scfg_regmap;
+
+   scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
+   if (IS_ERR(scfg_regmap)) {
+   pr_err("No syscfg phandle specified\n");
+   return;
+   }
+
+   regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_DISABLE);
+}
+
+void dcu_pixclk_enable(void)
+{
+   struct regmap *scfg_regmap;
+
+   scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
+   if (IS_ERR(scfg_regmap)) {
+   pr_err("No syscfg phandle specified\n");
+   return;
+   }
+
+   regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_ENABLE);
+}
+
+static void __init ls1021a_init_machine(void)
+{
+   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+   dcu_pixclk_enable();
+}
 static const char * const ls1021a_dt_compat[] __initconst = {
"fsl,ls1021a",
NULL,
@@ -18,5 +53,6 @@ static const char * const ls1021a_dt_compat[] __initconst = {

 DT_MACHINE_START(LS1021A, "Freescale LS1021A")
.smp= smp_ops(ls1021a_smp_ops),
+   .init_machine   = ls1021a_init_machine,
.dt_compat  = ls1021a_dt_compat,
 MACHINE_END
diff --git a/include/linux/fsl/dcu.h b/include/linux/fsl/dcu.h
new file mode 100644
index 000..1873057
--- /dev/null
+++ b/include/linux/fsl/dcu.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * Freescale DCU drm device driver
+ *
+ * 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.
+ */
+
+#ifndef __FSL_DCU_H__
+#define __FSL_DCU_H__
+
+#define SCFG_PIXCLKCR  0x28
+#define PXCK_ENABLEBIT(31)
+#define PXCK_DISABLE   0
+
+void dcu_pixclk_enable(void);
+void dcu_pixclk_disable(void);
+
+#endif /* __FSL_DCU_H__ */
-- 
2.1.0.27.g96db324



[PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver

2015-03-26 Thread Jianwei Wang
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) For the current LCD panel, WQVGA "480x272" is supported.
(3) Blending of each pixel using up to 4 source layers
dependent on size of panel.
(4) Each graphic layer can be placed with one pixel resolution
in either axis.
(5) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel
and BGRA direct colors with an alpha channel.
(6) Each graphic layer support alpha blending with 8-bit
resolution.

This is a simplified version, only one primary plane, one
framebuffer created for fbdev, one crtc, one connector for
TFT LCD panel, an encoder.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---

Changed in V3:

- Test driver on Vybrid board and add compatible string
- Remove unused functions
- set default crtc for encoder
- replace legacy functions with atomic help functions
- Set the unique name of the DRM device
- Implement irq handle function for vblank interrupt

Changed in v2: 
- Add atomic support
- Modify bindings file
- Rename node for compatibility
- Move platform related code out for compatibility

 .../devicetree/bindings/drm/fsl/fsl,dcu.txt|  50 
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/fsl/Kconfig|  17 ++
 drivers/gpu/drm/fsl/Makefile   |   8 +
 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c| 193 
 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h|  30 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 165 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  26 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 331 +
 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 210 +
 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  26 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  42 +++
 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  17 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 192 
 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  23 ++
 16 files changed, 1333 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
 create mode 100644 drivers/gpu/drm/fsl/Kconfig
 create mode 100644 drivers/gpu/drm/fsl/Makefile
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h

diff --git a/Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt 
b/Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
new file mode 100644
index 000..bdc7d5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/fsl/fsl,dcu.txt
@@ -0,0 +1,50 @@
+Device Tree bindings for Freescale DCU DRM Driver
+
+Required properties:
+- compatible:   Should be one of
+   * "fsl,ls1021a-dcu".
+   * "fsl,vf610-dcu".
+- reg:  Address and length of the register set for dcu.
+- clocks:   From common clock binding: handle to dcu clock.
+- clock-names:  From common clock binding: Shall be "dcu".
+- display:  The phandle to display node.
+
+Required properties:
+- bits-per-pixel:   <16> for RGB565,
+   <24> for RGB888,
+   <32> for RGB.
+
+Required timing node for dispplay sub-node:
+- display-timings:  Refer to binding doc display-timing.txt for details.
+
+Examples:
+dcu: dcu at 2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   clocks = <&platform_clk 0>;
+   clock-names = "dcu";
+   big-endian

[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89746

--- Comment #11 from Ming-Wei Shih  ---
It not solved with #7, but things behave differently now.

It's still hit and miss to get it running but when it fails it doesn't crash
any more, just gives an error that it cannot connect to the vm.

What's strange though is that when it fails I don't get any debugging at all,
so that that means there is a problem with genymotion itself? But then why this
never happens with llvm 3.5?

As far as I can tell genymotion's player (the part using OpenGL) is
multi-threaded and I can't find a way to disabled it.

Attached a successful run in #10, don't know if that's helpful at all.

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


[git pull] drm urgent fix

2015-03-26 Thread Dave Airlie
On 26 March 2015 at 13:04, Linus Torvalds  
wrote:
> On Wed, Mar 25, 2015 at 3:43 PM, Linus Torvalds
>  wrote:
>>
>> I'm going to wait a bit more with this, since clearly things are still
>> in flux, and these two commits don't actually fix everything at all.
>>
>> There's apparently at least one more fix necessary.
>
> Indeed. I can see the problem myself.
>
> With current git I get two warnings:
>
>WARNING: CPU: 3 PID: 325 at include/linux/kref.h:47
> drm_framebuffer_reference+0x72/0x80 [drm]()
>WARNING: CPU: 4 PID: 107 at drivers/gpu/drm/drm_atomic.c:482
> drm_atomic_check_only+0x32d/0x4f0 [drm]()
>
> and testing the pull it gets rid of the first one, but no tthe second one.
>
> So that urgent fix is very much still lacking.

I've pushed a drm-fixes-staging branch that backport's Daniel's
drm-next fix from 9 hours ago,

However it isn't tested yet, so if you want to give it a whirl grab it.

Hopefully when Daniel comes on line he can provide assurance that my
fix is a correct backport.

Dave.


[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89746

--- Comment #10 from Ming-Wei Shih  ---
Created attachment 114646
  --> https://bugs.freedesktop.org/attachment.cgi?id=114646&action=edit
[DEBUG] successful launch

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


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread Michael S. Tsirkin
On Thu, Mar 26, 2015 at 12:38:43PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > Absolutely, it's pretty common to mix regions in a BAR.
> > For example, we have virtio kick (ioeventfd backed,
> > handled in kernel) in same BAR as common and device
> > specific configuration.
> 
> > We did the same thing you are now doing with the
> > virtio BAR, and now we have to maintain two code
> > bases, virtio pci config was designed to be future proof
> > so why not use it?
> 
> It's not about virtio at all.  It's about vga compatibility, so we have
> a simple framebuffer as boot display.  Only used when virtio is *not*
> enabled.
> 

I don't know. This seems exactly like the kind of thing
we had in mind when we added the virtio pci capability.
For example, we have text in spec that requires drivers
to skip unknown capabilities.

And yes, if bios pokes at a specific bar then we do
need to list this info in the virtio spec so this makes
it an issue that is virtio related.


> > This is mostly just making sure we don't paint ourselves into a corner.
> 
> It's a simple memory bar.  vga cards have that since pci was invented
> (standalone ones, chipset graphics aside), and there havn't been
> fundamental changes ...
> 
> cheers,
>   Gerd
> 

Yes, it's not about what we put there now. It's about being able
to move things about in the future without breaking guests.

-- 
MST


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread Gerd Hoffmann
  Hi,

> Absolutely, it's pretty common to mix regions in a BAR.
> For example, we have virtio kick (ioeventfd backed,
> handled in kernel) in same BAR as common and device
> specific configuration.

> We did the same thing you are now doing with the
> virtio BAR, and now we have to maintain two code
> bases, virtio pci config was designed to be future proof
> so why not use it?

It's not about virtio at all.  It's about vga compatibility, so we have
a simple framebuffer as boot display.  Only used when virtio is *not*
enabled.

> This is mostly just making sure we don't paint ourselves into a corner.

It's a simple memory bar.  vga cards have that since pci was invented
(standalone ones, chipset graphics aside), and there havn't been
fundamental changes ...

cheers,
  Gerd




[PATCH] drm/tegra: Reset the SOR during initialization

2015-03-26 Thread Dmitry Osipenko
25.03.2015 11:59, Tomeu Vizoso пишет:
> As there isn't a way for the firmware on the Nyan chromebooks to hand
> over the display to the kernel, and the kernel isn't redoing the whole
> configuration at present.
>
> With this patch, the SOR is brought to a known state and we get correct
> display on every boot.
>
> Signed-off-by: Tomeu Vizoso 
>
> ---
>
> v7:   * Move the reset to the host1x_client_ops.init callback as
>   suggested by Thierry
>   * Reduced the time during which the reset line is asserted from
>   20ms to 2ms
> ---
>   drivers/gpu/drm/tegra/sor.c | 18 ++
>   1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 2afe478..027a25d22 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -1354,12 +1354,30 @@ static int tegra_sor_init(struct host1x_client 
> *client)
>   }
>   }
>
> + /*
> +  * XXX: Remove this reset once proper hand-over from firmware to
> +  * kernel is possible.
> +  */
> + err = reset_control_assert(sor->rst);
> + if (err < 0) {
> + dev_err(sor->dev, "failed to assert SOR reset: %d\n", err);
> + return err;
> + }
> +
>   err = clk_prepare_enable(sor->clk);
>   if (err < 0) {
>   dev_err(sor->dev, "failed to enable clock: %d\n", err);
>   return err;
>   }
>
> + msleep(2);
> +
> + err = reset_control_deassert(sor->rst);
> + if (err < 0) {
> + dev_err(sor->dev, "failed to deassert SOR reset: %d\n", err);
> + return err;
> + }
> +
>   err = clk_prepare_enable(sor->clk_safe);
>   if (err < 0)
>   return err;
>

According to kernel doc, you should use usleep_range() instead of msleep().

https://www.kernel.org/doc/Documentation/timers/timers-howto.txt

-- 
Dmitry


[PATCH v2 3/6] drm/exynos: mic: add MIC driver

2015-03-26 Thread Hyungwon Hwang
Dear Inki dae,

Sorry for the previous mail which is not completed. I typed something
and it was the shortcut for maybe.

On Tue, 24 Mar 2015 14:51:31 +0900
Inki Dae  wrote:

> On 2015년 03월 18일 17:16, Hyungwon Hwang wrote:
> > MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
> > resides between decon and mipi dsim, and compresses frame data by
> > 50%. With dsi, not display port, to send frame data to the panel,
> > the bandwidth is not enough. That is why this compressor is
> > introduced.
> > 
> > Signed-off-by: Hyungwon Hwang 
> > ---
> > Changes for v2:
> > - make mic driver to be registered by exynos drm driver instead as
> > a module  |
> > -
> > driver
> > |
> > -
> > - change the description of mic driver in documentation
> > - add module author at the top of the source file removing
> > MODULE_OWNER, MODULE_DESCRIPTION, MODULE_LICENSE
> >  .../devicetree/bindings/video/exynos-mic.txt   |  49 +++
> >  drivers/gpu/drm/exynos/Kconfig |   6 +
> >  drivers/gpu/drm/exynos/Makefile|   1 +
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
> >  drivers/gpu/drm/exynos/exynos_drm_mic.c| 481
> > + 6 files changed, 541 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/video/exynos-mic.txt create mode
> > 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c
> > 
> > diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt
> > b/Documentation/devicetree/bindings/video/exynos-mic.txt new file
> > mode 100644 index 000..006d072
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/exynos-mic.txt
> > @@ -0,0 +1,49 @@
> > +Device-Tree bindings for Samsung Exynos SoC mobile image
> > compressor (MIC) +
> > +MIC (mobile image compressor) resides between decon and mipi dsi.
> > Mipi dsi is +not capable to transfer high resoltuion frame data as
> > decon can send. MIC +solves this problem by compressing the frame
> > data by 1/2 before it is transfered +through mipi dsi. The
> > compressed frame data must be uncompressed in the panel +PCB.
> > +
> > +Required properties:
> > +- compatible: value should be "samsung,exynos5433-mic".
> > +- reg: physical base address and length of the MIC registers set
> > and system
> > +   register of mic.
> > +- clocks: must include clock specifiers corresponding to entries
> > in the
> > + clock-names property.
> > +- clock-names: list of clock names sorted in the same order as the
> > clocks
> > +  property. Must contain "pclk_mic0",
> > "sclk_rgb_vclk_to_mic0". +- ports: contains a port which is
> > connected to decon node and dsi node.
> > +address-cells and size-cells must 1 and 0, respectively.
> > +- port: contains an endpoint node which is connected to the
> > endpoint in the
> > +   decon node or dsi node. The reg value must be 0 and 1
> > respectively. +
> > +Example:
> > +SoC specific DT entry:
> > +mic: mic at 1393 {
> > +   compatible = "samsung,exynos5433-mic";
> > +   reg = <0x1393 0x48 0x13B8 0x1010>;
> > +   clocks = <&cmu_disp CLK_PCLK_MIC0>,
> > +  <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>;
> > +   clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0";
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port at 0 {
> > +   reg = <0>;
> > +   mic_to_decon: endpoint {
> > +   remote-endpoint = <&decon_to_mic>;
> > +   };
> > +   };
> > +
> > +   port at 1 {
> > +   reg = <1>;
> > +   mic_to_dsi: endpoint {
> > +   remote-endpoint = <&dsi_to_mic>;
> > +   };
> > +   };
> > +   };
> > +};
> > diff --git a/drivers/gpu/drm/exynos/Kconfig
> > b/drivers/gpu/drm/exynos/Kconfig index e15cc2e..a796175 100644
> > --- a/drivers/gpu/drm/exynos/Kconfig
> > +++ b/drivers/gpu/drm/exynos/Kconfig
> > @@ -103,3 +103,9 @@ config DRM_EXYNOS_GSC
> > depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5
> > && !ARCH_MULTIPLATFORM help
> >   Choose this option if you want to use Exynos GSC for DRM.
> > +
> > +config DRM_EXYNOS_MIC
> > +   bool "Exynos DRM MIC"
> > +   depends on (DRM_EXYNOS && DRM_EXYNOS5433_DECON)
> > +   help
> > + Choose this option if you want to use Exynos MIC for DRM.
> > diff --git a/drivers/gpu/drm/exynos/Makefile
> > b/drivers/gpu/drm/exynos/Makefile index fbd084d..7de0b10 100644
> > --- a/drivers/gpu/drm/exynos/Makefile
> > +++ b/drivers/gpu/drm/exynos/Makefile
> > @@ -22,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+=
> > exyno

[PATCH v2 3/6] drm/exynos: mic: add MIC driver

2015-03-26 Thread Hyungwon Hwang
Dear Inki dae,

On Tue, 24 Mar 2015 14:51:31 +0900
Inki Dae  wrote:

> On 2015년 03월 18일 17:16, Hyungwon Hwang wrote:
> > MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
> > resides between decon and mipi dsim, and compresses frame data by
> > 50%. With dsi, not display port, to send frame data to the panel,
> > the bandwidth is not enough. That is why this compressor is
> > introduced.
> > 
> > Signed-off-by: Hyungwon Hwang 
> > ---
> > Changes for v2:
> > - make mic driver to be registered by exynos drm driver instead as
> > a module  |
> > -
> > driver
> > |
> > -
> > - change the description of mic driver in documentation
> > - add module author at the top of the source file removing
> > MODULE_OWNER, MODULE_DESCRIPTION, MODULE_LICENSE
> >  .../devicetree/bindings/video/exynos-mic.txt   |  49 +++
> >  drivers/gpu/drm/exynos/Kconfig |   6 +
> >  drivers/gpu/drm/exynos/Makefile|   1 +
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
> >  drivers/gpu/drm/exynos/exynos_drm_mic.c| 481
> > + 6 files changed, 541 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/video/exynos-mic.txt create mode
> > 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c
> > 
> > diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt
> > b/Documentation/devicetree/bindings/video/exynos-mic.txt new file
> > mode 100644 index 000..006d072
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/exynos-mic.txt
> > @@ -0,0 +1,49 @@
> > +Device-Tree bindings for Samsung Exynos SoC mobile image
> > compressor (MIC) +
> > +MIC (mobile image compressor) resides between decon and mipi dsi.
> > Mipi dsi is +not capable to transfer high resoltuion frame data as
> > decon can send. MIC +solves this problem by compressing the frame
> > data by 1/2 before it is transfered +through mipi dsi. The
> > compressed frame data must be uncompressed in the panel +PCB.
> > +
> > +Required properties:
> > +- compatible: value should be "samsung,exynos5433-mic".
> > +- reg: physical base address and length of the MIC registers set
> > and system
> > +   register of mic.
> > +- clocks: must include clock specifiers corresponding to entries
> > in the
> > + clock-names property.
> > +- clock-names: list of clock names sorted in the same order as the
> > clocks
> > +  property. Must contain "pclk_mic0",
> > "sclk_rgb_vclk_to_mic0". +- ports: contains a port which is
> > connected to decon node and dsi node.
> > +address-cells and size-cells must 1 and 0, respectively.
> > +- port: contains an endpoint node which is connected to the
> > endpoint in the
> > +   decon node or dsi node. The reg value must be 0 and 1
> > respectively. +
> > +Example:
> > +SoC specific DT entry:
> > +mic: mic at 1393 {
> > +   compatible = "samsung,exynos5433-mic";
> > +   reg = <0x1393 0x48 0x13B8 0x1010>;
> > +   clocks = <&cmu_disp CLK_PCLK_MIC0>,
> > +  <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>;
> > +   clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0";
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port at 0 {
> > +   reg = <0>;
> > +   mic_to_decon: endpoint {
> > +   remote-endpoint = <&decon_to_mic>;
> > +   };
> > +   };
> > +
> > +   port at 1 {
> > +   reg = <1>;
> > +   mic_to_dsi: endpoint {
> > +   remote-endpoint = <&dsi_to_mic>;
> > +   };
> > +   };
> > +   };
> > +};
> > diff --git a/drivers/gpu/drm/exynos/Kconfig
> > b/drivers/gpu/drm/exynos/Kconfig index e15cc2e..a796175 100644
> > --- a/drivers/gpu/drm/exynos/Kconfig
> > +++ b/drivers/gpu/drm/exynos/Kconfig
> > @@ -103,3 +103,9 @@ config DRM_EXYNOS_GSC
> > depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5
> > && !ARCH_MULTIPLATFORM help
> >   Choose this option if you want to use Exynos GSC for DRM.
> > +
> > +config DRM_EXYNOS_MIC
> > +   bool "Exynos DRM MIC"
> > +   depends on (DRM_EXYNOS && DRM_EXYNOS5433_DECON)
> > +   help
> > + Choose this option if you want to use Exynos MIC for DRM.
> > diff --git a/drivers/gpu/drm/exynos/Makefile
> > b/drivers/gpu/drm/exynos/Makefile index fbd084d..7de0b10 100644
> > --- a/drivers/gpu/drm/exynos/Makefile
> > +++ b/drivers/gpu/drm/exynos/Makefile
> > @@ -22,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+=
> > exynos_drm_ipp.o exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+=
> > exynos_drm_fimc.o exynosdrm-$(CONFIG_DRM_EXY

[PATCH 1/3] drm/exynos: mixer: add 2x scaling to mixer_graph_buffer

2015-03-26 Thread Gustavo Padovan
Hi Tobias,

2015-03-26 Tobias Jakobi :

> While the VP (video processor) supports arbitrary scaling
> of its input, the mixer just supports a simple 2x (line
> doubling) scaling. Expose this functionality and exit
> early when an unsupported scaling configuration is
> encountered.
> 
> This was tested with modetest's DRM plane test (from
> the libdrm test suite) on an Odroid-X2 (Exynos4412).
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 38 
> +--
>  1 file changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index df547b6..7c38d3b 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -521,12 +521,37 @@ static void mixer_layer_update(struct mixer_context 
> *ctx)
>   mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
>  }
>  
> +static int mixer_setup_scale(unsigned int src_w, unsigned int src_h,
> + unsigned int dst_w, unsigned int dst_h,
> + unsigned int *scale_w, unsigned int *scale_h)

I would keep calling these two vars x_ratio and y_ratio. I don't see a reason
to change the name here.

> +{
> + if (dst_w != src_w) {
> + if (dst_w == 2 * src_w)
> + *scale_w = 1;
> + else
> + goto fail;
> + }
> +
> + if (dst_h != src_h) {
> + if (dst_h == 2 * src_h)
> + *scale_h = 1;
> + else
> + goto fail;
> + }
> +
> + return 0;
> +
> +fail:
> + DRM_DEBUG_KMS("only 2x width/height scaling of plane supported\n");
> + return -1;

Use EPERM or ENOTSUPP. Or even true/false.

> +}
> +
>  static void mixer_graph_buffer(struct mixer_context *ctx, int win)
>  {
>   struct mixer_resources *res = &ctx->mixer_res;
>   unsigned long flags;
>   struct hdmi_win_data *win_data;
> - unsigned int x_ratio, y_ratio;
> + unsigned int x_ratio = 0, y_ratio = 0;
>   unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
>   dma_addr_t dma_addr;
>   unsigned int fmt;
> @@ -550,9 +575,10 @@ static void mixer_graph_buffer(struct mixer_context 
> *ctx, int win)
>   fmt = ARGB;
>   }
>  
> - /* 2x scaling feature */
> - x_ratio = 0;
> - y_ratio = 0;
> + /* check if mixer supports scaling setup */
> + if (mixer_setup_scale(win_data->src_width, win_data->src_height,
> + win_data->crtc_width, win_data->crtc_height,
> + &x_ratio, &y_ratio)) return;

You need to fix style here

if (mixer_setup_scale(win_data->src_width, win_data->src_height,
  win_data->crtc_width, win_data->crtc_height,  
  &x_ratio, &y_ratio))  
return; 


I think your patch is good after these things get fixes and we can go with it
and drop mine. Then I'll just rebase the alpha channel fix patch on top of
this one.

Gustavo


[PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio

2015-03-26 Thread Mark Brown
On Sat, Feb 28, 2015 at 10:04:30PM -0500, Yakir Yang wrote:

> + ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt);
> + if (ret < 0) {
> + dev_err(cpu_dai->dev, "failed to set cpu_dai fmt.\n");
> + return ret;
> + }

You've already set this in the dai_link, no need to do it again.

> + dev_info(&pdev->dev, "hdmi audio init success.\n");

Please remove noisy prints like this.

> +free_cpu_of_node:
> + hdmi_audio_dai.cpu_of_node = NULL;
> + hdmi_audio_dai.platform_of_node = NULL;
> +free_priv_data:
> + snd_soc_card_set_drvdata(card, NULL);
> + platform_set_drvdata(pdev, NULL);
> + card->dev = NULL;

If any of these assignments is doing anything there's a problem with the
code.

> +{
> + struct snd_soc_card *card = platform_get_drvdata(pdev);
> +
> + snd_soc_unregister_card(card);

devm_snd_soc_register_card() and you can remove this function entirely.

> +static const struct of_device_id rockchip_hdmi_audio_of_match[] = {
> + { .compatible = "rockchip,rk3288-hdmi-audio", },
> + {},
> +};

There is no documentation for this binding, binding documentation is
mandatory.  Based on the compatible string this looks like it's specific
to the SoC rather than a design for a board - is the whole card part of
the SoC?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/62978135/attachment-0001.sig>


[PATCH v2 1/6] drm/exynos: add Exynos5433 decon driver

2015-03-26 Thread Hyungwon Hwang
Dear Daniel,

On Wed, 18 Mar 2015 12:24:40 +
Daniel Stone  wrote:

> Hi,
> Some feedback comments - most of these are not unique to your 5433
> DECON driver but endemic throughout Exynos, so I don't blame you for
> them - but they should be fixed anyway.
> 
> On 18 March 2015 at 08:16, Hyungwon Hwang 
> wrote:
> > +static void decon_dpms_on(struct exynos_decon *decon)
> > +{
> > +   int ret;
> > +   int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
> > +   ret = clk_prepare_enable(decon->clks[i]);
> > +   if (ret < 0)
> > +   goto err;
> > +   }
> > +
> > +   set_bit(BIT_CLKS_ENABLED, &decon->enabled);
> 
> Do you really not even need to set a control register?
> 
> > +static void decon_commit(struct exynos_drm_crtc *crtc)
> > +{
> > +   struct exynos_decon *decon = crtc->ctx;
> > +   struct drm_display_mode *mode = &crtc->base.mode;
> > +   u32 val;
> > +
> > +   /* enable clock gate */
> > +   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
> > +   writel(val, decon->addr + DECON_CMU);
> > +
> > +   /* lcd on and use command if */
> > +   val = VIDOUT_LCD_ON;
> > +   if (decon->i80_if)
> > +   val |= VIDOUT_COMMAND_IF;
> > +   else
> > +   val |= VIDOUT_RGB_IF;
> > +   writel(val, decon->addr + DECON_VIDOUTCON0);
> 
> This seems much more likely to be DPMS, no?
> 
> > +   [...]
> > +   /* enable output and display signal */
> > +   val = VIDCON0_ENVID | VIDCON0_ENVID_F;
> > +   writel(val, decon->addr + DECON_VIDCON0);
> 
> As does this.
> 
> Have you tested DPMS on/off, without enabling/disabling the CRTC
> first? Does it work?

Yes. I misunderstanded the behavior of the driver. I will send the
fixed version for working DPMS. Thanks.

> 
> > +static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
> > +  struct exynos_drm_plane *plane)
> > +{
> > +   struct exynos_decon *decon = crtc->ctx;
> > +   struct decon_reg_data *reg_data;
> > +   unsigned int bytes_per_pixel = plane->bpp >> 3;
> > +   unsigned int val_h;
> > +   unsigned int val_l;
> > +   unsigned int win;
> > +   dma_addr_t addr;
> > +   u32 val = 0;
> > +
> > +   if (!plane) {
> > +   DRM_ERROR("plane is NULL\n");
> > +   return;
> > +   }
> > +
> > +   win = plane->zpos;
> > +   if (win == DEFAULT_ZPOS)
> > +   win = 0;
> > +
> > +   if (win < 0 || win >= 5)
> > +   return;
> 
> It would be nice to have a #define for the largest-supported window
> number.

Yes. That would be better.

> 
> > +   reg_data = &decon->reg_data[win];
> > +
> > +   switch (plane->pixel_format) {
> > +   case DRM_FORMAT_XRGB1555:
> > +   val |= WINCONx_BPPMODE_16BPP_I1555;
> > +   val |= WINCONx_HAWSWP_F;
> > +   val |= WINCONx_BURSTLEN_16WORD;
> > +   break;
> > +   case DRM_FORMAT_RGB565:
> > +   val |= WINCONx_BPPMODE_16BPP_565;
> > +   val |= WINCONx_HAWSWP_F;
> > +   val |= WINCONx_BURSTLEN_16WORD;
> > +   break;
> > +   case DRM_FORMAT_XRGB:
> > +   val |= WINCONx_BPPMODE_24BPP_888;
> > +   val |= WINCONx_WSWP_F;
> > +   val |= WINCONx_BURSTLEN_16WORD;
> > +   break;
> > +   case DRM_FORMAT_ARGB:
> > +   val |= WINCONx_BPPMODE_32BPP_A;
> > +   val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F |
> > WINCONx_ALPHA_SEL_F;
> > +   val |= WINCONx_BURSTLEN_16WORD;
> > +   break;
> > +   default:
> 
> Please remove the 'default' case. If you get here with a format you
> don't know how to configure, then it is a bug and should be fixed: the
> plane should never advertise a format that it cannot support.
> 

Yes. I agree.

> > +   val |= WINCONx_BPPMODE_24BPP_888;
> > +   val |= WINCONx_WSWP_F;
> > +   val |= WINCONx_BURSTLEN_16WORD;
> > +   break;
> > +   }
> > +
> > +   reg_data->wincon = val;
> > +   reg_data->vidosd_a = COORDINATE_X(plane->crtc_x) |
> > +   COORDINATE_Y(plane->crtc_y);
> > +   reg_data->vidosd_b =
> > +   COORDINATE_X(plane->crtc_x + plane->crtc_width - 1)
> > |
> > +   COORDINATE_Y(plane->crtc_y + plane->crtc_height -
> > 1);
> > +   reg_data->vidosd_c = VIDOSD_Wx_ALPHA_R_F(0x0) |
> > +   VIDOSD_Wx_ALPHA_G_F(0x0) |
> > +   VIDOSD_Wx_ALPHA_B_F(0x0);
> > +   reg_data->vidosd_d = VIDOSD_Wx_ALPHA_R_F(0x0) |
> > +   VIDOSD_Wx_ALPHA_G_F(0x0) |
> > +   VIDOSD_Wx_ALPHA_B_F(0x0);
> > +
> > +   addr = plane->dma_addr[0];
> > +   addr += plane->fb_width * plane->fb_y * bytes_per_pixel;
> 
>

[PATCH v4 13/15] ASoC: codec/dw-hdmi-audio: add codec driver for dw hdmi audio

2015-03-26 Thread Mark Brown
On Sat, Feb 28, 2015 at 09:59:20PM -0500, Yakir Yang wrote:

> codec driver creat an standard alsa device, than config audio
> and report jack status through some callback interfaces that
> dw_hdmi driver support.

Looking at this it's not althogether clear to me how specific this is to
the Designware hardware - it looks like it's all callbacks into the main
driver doing pretty generic things apart from the fact that we request
an interrupt here (but then use it to do another callback into the
driver).

Please also try to only CC relevant people on mails - you've got a
*very* large list of people there and for a lot of them it's hard to
understand why you've copied them.  Copying people adds to the amount of
mail they need to read so it's good to try to stay relevant.

> + if (jack_status != hdmi->jack_status) {
> + snd_soc_jack_report(&hdmi->jack, jack_status,
> + SND_JACK_LINEOUT);

We may need a new jack type here, or perhaps we ought to just be
reporting the jack status via extcon?

> + hdmi->jack_status = jack_status;
> +
> + dev_info(hdmi->dev, "jack report [%d]\n", hdmi->jack_status);

Please remove this and all the other prints, it's far too noisy.

> +/* we don't want this irq mark with IRQF_ONESHOT flags,
> + * so we build an irq_default_primary_handler here */
> +static irqreturn_t snd_dw_hdmi_hardirq(int irq, void *dev_id)
> +{
> + return IRQ_WAKE_THREAD;
> +}

Why do we not want to use IRQF_ONESHOT?

> +static int dw_hdmi_audio_remove(struct platform_device *pdev)
> +{
> + struct snd_dw_hdmi *hdmi = platform_get_drvdata(pdev);
> +
> + snd_soc_unregister_codec(&pdev->dev);
> + devm_free_irq(&pdev->dev, hdmi->data.irq, hdmi);
> + devm_kfree(&pdev->dev, hdmi);

Explicitly freeing devm_ things seems to be missing the point a bit...

> +static const struct of_device_id dw_hdmi_audio_ids[] = {
> + { .compatible = DRV_NAME, },
> + { }
> +};

Your driver name didn't have a vendor prefix, this is broken - you
should probably just remove DRV_NAME and use the string directly in the
few places it's used.  It's also not clear to me that this is a separate
device from the parent device and should therefore appear separately in
DT at all.

> +static struct platform_driver dw_hdmi_audio_driver = {
> + .driver = {
> + .name = DRV_NAME,
> + .owner = THIS_MODULE,

No need to assign owner any more.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/b8ae3c07/attachment.sig>


[PATCH -v2 8/8] drm/exynos: track vblank events on a per crtc basis

2015-03-26 Thread Gustavo Padovan
From: Mandeep Singh Baines 

The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.

Simplified the code by tracking vblank events on a per-crtc basis. This
allowed me to remove all error paths from the callback. It also allowed
me to remove the vblank wait from the callback.

Signed-off-by: Mandeep Singh Baines 
Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 92 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  | 13 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 +--
 3 files changed, 44 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 47dd2b0..eb49195 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
-   !atomic_read(&exynos_crtc->pending_flip),
-   HZ/20))
-   atomic_set(&exynos_crtc->pending_flip, 0);
+   (exynos_crtc->event == NULL), HZ/20))
+   exynos_crtc->event = NULL;
drm_crtc_vblank_off(crtc);
}

@@ -164,11 +163,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 uint32_t page_flip_flags)
 {
struct drm_device *dev = crtc->dev;
-   struct exynos_drm_private *dev_priv = dev->dev_private;
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned int crtc_w, crtc_h;
-   int ret = -EINVAL;
+   int ret;

/* when the page flip is requested, crtc's dpms should be on */
if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) {
@@ -176,48 +174,49 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
*crtc,
return -EINVAL;
}

-   mutex_lock(&dev->struct_mutex);
+   if (!event)
+   return -EINVAL;

-   if (event) {
-   /*
-* the pipe from user always is 0 so we can set pipe number
-* of current owner to event.
-*/
-   event->pipe = exynos_crtc->pipe;
+   spin_lock_irq(&dev->event_lock);
+   if (exynos_crtc->event) {
+   ret = -EBUSY;
+   goto out;
+   }

-   ret = drm_vblank_get(dev, exynos_crtc->pipe);
-   if (ret) {
-   DRM_DEBUG("failed to acquire vblank counter\n");
+   ret = drm_vblank_get(dev, exynos_crtc->pipe);
+   if (ret) {
+   DRM_DEBUG("failed to acquire vblank counter\n");
+   goto out;
+   }

-   goto out;
-   }
+   exynos_crtc->event = event;
+   spin_unlock_irq(&dev->event_lock);

+   /*
+* the pipe from user always is 0 so we can set pipe number
+* of current owner to event.
+*/
+   event->pipe = exynos_crtc->pipe;
+
+   crtc->primary->fb = fb;
+   crtc_w = fb->width - crtc->x;
+   crtc_h = fb->height - crtc->y;
+   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
+ crtc_w, crtc_h, crtc->x, crtc->y,
+ crtc_w, crtc_h);
+   if (ret) {
+   crtc->primary->fb = old_fb;
spin_lock_irq(&dev->event_lock);
-   list_add_tail(&event->base.link,
-   &dev_priv->pageflip_event_list);
-   atomic_set(&exynos_crtc->pending_flip, 1);
+   exynos_crtc->event = NULL;
+   drm_vblank_put(dev, exynos_crtc->pipe);
spin_unlock_irq(&dev->event_lock);
-
-   crtc->primary->fb = fb;
-   crtc_w = fb->width - crtc->x;
-   crtc_h = fb->height - crtc->y;
-   ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0,
- crtc_w, crtc_h, crtc->x, crtc->y,
- crtc_w, crtc_h);
-   if (ret) {
-   crtc->primary->fb = old_fb;
-
-   spin_lock_irq(&dev->event_lock);
-   drm_vblank_put(dev, exynos_crtc->pipe);
-   list_del(&event->base.link);
-   atomic_set(&exynos_crtc->pending_flip, 0);
-   spin_unlock_irq(&dev->event_lock);
-
-   goto out;
-   }
+   return ret;
}
+
+   return 0;
+
 out:
-   mutex_

[PATCH -v2 7/8] drm/exynos: remove leftover functions declarations

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

These functions were already removed by previous cleanup work, but these
ones were left behind.

Signed-off-by: Gustavo Padovan 
Acked-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index e1fd2ef..0ecd8fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -28,12 +28,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev, 
int pipe);
 void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe);
 void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);

-void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
-   struct exynos_drm_plane *plane);
-void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos);
-void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
-void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
-
 /* This function gets pipe value to crtc device matched with out_type. */
 int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);
-- 
2.1.0



[PATCH -v2 6/8] drm/exynos: remove exynos_plane_destroy()

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 2fbac9b..2b0479e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -178,16 +178,10 @@ static int exynos_disable_plane(struct drm_plane *plane)
return 0;
 }

-static void exynos_plane_destroy(struct drm_plane *plane)
-{
-   exynos_disable_plane(plane);
-   drm_plane_cleanup(plane);
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = exynos_update_plane,
.disable_plane  = exynos_disable_plane,
-   .destroy= exynos_plane_destroy,
+   .destroy= drm_plane_cleanup,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
-- 
2.1.0



[PATCH -v2 5/8] drm/exynos: make zpos property immutable

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 504bd6e..2fbac9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -184,27 +184,10 @@ static void exynos_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }

-static int exynos_plane_set_property(struct drm_plane *plane,
-struct drm_property *property,
-uint64_t val)
-{
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_private *dev_priv = dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property) {
-   exynos_plane->zpos = val;
-   return 0;
-   }
-
-   return -EINVAL;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = exynos_update_plane,
.disable_plane  = exynos_disable_plane,
.destroy= exynos_plane_destroy,
-   .set_property   = exynos_plane_set_property,
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
@@ -216,8 +199,8 @@ static void exynos_plane_attach_zpos_property(struct 
drm_plane *plane,

prop = dev_priv->plane_zpos_property;
if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos", 0,
-MAX_PLANE - 1);
+   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
+"zpos", 0, MAX_PLANE - 1);
if (!prop)
return;

-- 
2.1.0



[PATCH -v2 4/8] drm/exynos: preset zpos value for overlay planes

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.

Also all places that were storing zpos positions are now unsigned int.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 20 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  7 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  | 16 +---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |  3 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 17 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 11 +--
 7 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 2cbe328..bee1f72 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -378,7 +378,7 @@ static void decon_win_set_colkey(struct decon_context *ctx, 
unsigned int win)
  * @protect: 1 to protect (disable updates)
  */
 static void decon_shadow_protect_win(struct decon_context *ctx,
-   int win, bool protect)
+unsigned int win, bool protect)
 {
u32 bits, val;

@@ -392,12 +392,12 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx,
writel(val, ctx->regs + SHADOWCON);
 }

-static void decon_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
 {
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *mode = &crtc->base.mode;
struct exynos_drm_plane *plane;
-   int padding, win = zpos;
+   int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
@@ -405,9 +405,6 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc, 
int zpos)
if (ctx->suspended)
return;

-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;

@@ -513,16 +510,12 @@ static void decon_win_commit(struct exynos_drm_crtc 
*crtc, int zpos)
plane->enabled = true;
 }

-static void decon_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
 {
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
-   int win = zpos;
u32 val;

-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
if (win < 0 || win >= WINDOWS_NR)
return;

@@ -764,7 +757,8 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
enum drm_plane_type type;
-   int zpos, ret;
+   unsigned int zpos;
+   int ret;

ret = decon_ctx_initialize(ctx, drm_dev);
if (ret) {
@@ -776,7 +770,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, &ctx->planes[zpos], 1 << ctx->pipe,
- type);
+ type, zpos);
}

exynos_plane = &ctx->planes[ctx->default_win];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8a2f943..26d6de1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -21,7 +21,6 @@
 #define MAX_CRTC   3
 #define MAX_PLANE  5
 #define MAX_FB_BUFFER  4
-#define DEFAULT_ZPOS   -1

 #define to_exynos_crtc(x)  container_of(x, struct exynos_drm_crtc, base)
 #define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
@@ -104,7 +103,7 @@ struct exynos_drm_plane {
unsigned int pitch;
uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
-   int zpos;
+   unsigned int zpos;
unsigned int index_color;

bool default_win:1;
@@ -189,8 +188,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
-   void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
-   void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
+   void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+   void (*win_disable)

[PATCH -v2 3/8] drm/exynos: remove struct *_win_data abstraction on planes

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.

It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 164 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   9 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  14 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   5 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 182 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  23 +---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 123 -
 drivers/gpu/drm/exynos/exynos_mixer.c  | 212 ++---
 10 files changed, 242 insertions(+), 497 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..2cbe328 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -28,6 +28,7 @@
 #include 

 #include "exynos_drm_crtc.h"
+#include "exynos_drm_plane.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_iommu.h"
@@ -41,32 +42,16 @@

 #define WINDOWS_NR 2

-struct decon_win_data {
-   unsigned intovl_x;
-   unsigned intovl_y;
-   unsigned intoffset_x;
-   unsigned intoffset_y;
-   unsigned intovl_width;
-   unsigned intovl_height;
-   unsigned intfb_width;
-   unsigned intfb_height;
-   unsigned intbpp;
-   unsigned intpixel_format;
-   dma_addr_t  dma_addr;
-   boolenabled;
-   boolresume;
-};
-
 struct decon_context {
struct device   *dev;
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
+   struct exynos_drm_plane planes[WINDOWS_NR];
struct clk  *pclk;
struct clk  *aclk;
struct clk  *eclk;
struct clk  *vclk;
void __iomem*regs;
-   struct decon_win_data   win_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long   irq_flags;
booli80_if;
@@ -296,59 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
}
 }

-static void decon_win_mode_set(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
-{
-   struct decon_context *ctx = crtc->ctx;
-   struct decon_win_data *win_data;
-   int win, padding;
-
-   if (!plane) {
-   DRM_ERROR("plane is NULL\n");
-   return;
-   }
-
-   win = plane->zpos;
-   if (win == DEFAULT_ZPOS)
-   win = ctx->default_win;
-
-   if (win < 0 || win >= WINDOWS_NR)
-   return;
-
-
-   win_data = &ctx->win_data[win];
-
-   padding = (plane->pitch / (plane->bpp >> 3)) - plane->fb_width;
-   win_data->offset_x = plane->fb_x;
-   win_data->offset_y = plane->fb_y;
-   win_data->fb_width = plane->fb_width + padding;
-   win_data->fb_height = plane->fb_height;
-   win_data->ovl_x = plane->crtc_x;
-   win_data->ovl_y = plane->crtc_y;
-   win_data->ovl_width = plane->crtc_width;
-   win_data->ovl_height = plane->crtc_height;
-   win_data->dma_addr = plane->dma_addr[0];
-   win_data->bpp = plane->bpp;
-   win_data->pixel_format = plane->pixel_format;
-
-   DRM_DEBUG_KMS("offset_x = %d, offset_y = %d\n",
-   win_data->offset_x, win_data->offset_y);
-   DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
-   win_data->ovl_width, win_data->ovl_height);
-   DRM_DEBUG_KMS("paddr = 0x%lx\n", (unsigned long)win_data->dma_addr);
-   DRM_DEBUG_KMS("fb_width = %d, crtc_width = %d\n",
-   plane->fb_width, plane->crtc_width);
-}
-
 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
 {
-   struct decon_win_data *win_data = &ctx->win_data[win];
+   struct exynos_drm_plane *plane = &ctx->planes[win];
unsigned long val;
+   int padding;

val = readl(ctx->regs + WINCON(win));
val &= ~WINCONx_BPPMODE_MASK;

-   switch (win_data->pixel_format) {
+   switch (plane->pixel_format) {
case DRM_FORMAT_RGB565:
val |= WINCONx_BPPMODE_16BPP_565;
val |= WINCONx_BURSTLEN_16WORD;
@@ -397,7 +339,7 @@ static void decon_win_set_pixfmt(struc

[PATCH -v2 2/8] drm/exynos: remove unused exynos_crtc->win_enable() callback

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9afd390..4e8f0b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -174,7 +174,6 @@ struct exynos_drm_display {
  * hardware overlay is updated.
  * @win_mode_set: copy drm overlay info to hw specific overlay info.
  * @win_commit: apply hardware specific overlay data to registers.
- * @win_enable: enable hardware specific overlay.
  * @win_disable: disable hardware specific overlay.
  * @te_handler: trigger to transfer video image at the tearing effect
  * synchronization signal if there is a page flip request.
@@ -192,7 +191,6 @@ struct exynos_drm_crtc_ops {
void (*win_mode_set)(struct exynos_drm_crtc *crtc,
struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_crtc *crtc, int zpos);
-   void (*win_enable)(struct exynos_drm_crtc *crtc, int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
 };
-- 
2.1.0



[PATCH -v2 1/8] drm/exynos: fimd: fix alpha setting for XR24 pixel format

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

XR24 planes were not shown properly, so now set the right registers
to correctly enable displaying these planes.

It also moves the alpha register settings to fimd_win_set_pixfmt()
to keep all pixel format stuff together.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +--
 include/video/samsung_fimd.h |  5 +
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 925fc69..c7aa4c7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -54,6 +54,9 @@
 /* size control register for hardware windows 1 ~ 2. */
 #define VIDOSD_D(win)  (VIDOSD_BASE + 0x0C + (win) * 16)

+#define VIDWnALPHA0(win)   (VIDW_ALPHA + 0x00 + (win) * 8)
+#define VIDWnALPHA1(win)   (VIDW_ALPHA + 0x04 + (win) * 8)
+
 #define VIDWx_BUF_START(win, buf)  (VIDW_BUF_START(buf) + (win) * 8)
 #define VIDWx_BUF_END(win, buf)(VIDW_BUF_END(buf) + (win) * 8)
 #define VIDWx_BUF_SIZE(win, buf)   (VIDW_BUF_SIZE(buf) + (win) * 4)
@@ -623,6 +626,24 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, 
unsigned int win)
}

writel(val, ctx->regs + WINCON(win));
+
+   /* hardware window 0 doesn't support alpha channel. */
+   if (win != 0) {
+   /* OSD alpha */
+   val = VIDISD14C_ALPHA0_R(0xf) |
+   VIDISD14C_ALPHA0_G(0xf) |
+   VIDISD14C_ALPHA0_B(0xf) |
+   VIDISD14C_ALPHA1_R(0xf) |
+   VIDISD14C_ALPHA1_G(0xf) |
+   VIDISD14C_ALPHA1_B(0xf);
+
+   writel(val, ctx->regs + VIDOSD_C(win));
+
+   val = VIDW_ALPHA_R(0xf) | VIDW_ALPHA_G(0xf) |
+   VIDW_ALPHA_G(0xf);
+   writel(val, ctx->regs + VIDWnALPHA0(win));
+   writel(val, ctx->regs + VIDWnALPHA1(win));
+   }
 }

 static void fimd_win_set_colkey(struct fimd_context *ctx, unsigned int win)
@@ -747,16 +768,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc, 
int zpos)
DRM_DEBUG_KMS("osd pos: tx = %d, ty = %d, bx = %d, by = %d\n",
win_data->offset_x, win_data->offset_y, last_x, last_y);

-   /* hardware window 0 doesn't support alpha channel. */
-   if (win != 0) {
-   /* OSD alpha */
-   alpha = VIDISD14C_ALPHA1_R(0xf) |
-   VIDISD14C_ALPHA1_G(0xf) |
-   VIDISD14C_ALPHA1_B(0xf);
-
-   writel(alpha, ctx->regs + VIDOSD_C(win));
-   }
-
/* OSD size */
if (win != 3 && win != 4) {
u32 offset = VIDOSD_D(win);
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index a20e4a3..5132428 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -289,6 +289,11 @@
 #define VIDISD14C_ALPHA1_B_LIMIT   0xf
 #define VIDISD14C_ALPHA1_B(_x) ((_x) << 0)

+#define VIDW_ALPHA 0x021c
+#define VIDW_ALPHA_R(_x)   ((_x) << 16)
+#define VIDW_ALPHA_G(_x)   ((_x) << 8)
+#define VIDW_ALPHA_B(_x)   ((_x) << 0)
+
 /* Video buffer addresses */
 #define VIDW_BUF_START(_buff)  (0xA0 + ((_buff) * 8))
 #define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
-- 
2.1.0



[PATCH -v2 0/8] drm/exynos: clean up patches (preparing for atomic)

2015-03-26 Thread Gustavo Padovan
From: Gustavo Padovan 

Hi,

Here goes some clean ups to the exynos drivers. The main clean ups is
the presetting and zpos making the property immutable and the removal
of *_win_data structures.

v2 contains a extra patch to fix alpha setting for planes in fimd, so
now fimd works fine even after the removal of struct fimd_win_data.

Gustavo

---
Gustavo Padovan (7):
  drm/exynos: fimd: fix alpha setting for XR24 pixel format
  drm/exynos: remove unused exynos_crtc->win_enable() callback
  drm/exynos: remove struct *_win_data abstraction on planes
  drm/exynos: preset zpos value for overlay planes
  drm/exynos: make zpos property immutable
  drm/exynos: remove exynos_plane_destroy()
  drm/exynos: remove leftover functions declarations

Mandeep Singh Baines (1):
  drm/exynos: track vblank events on a per crtc basis

 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 176 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 101 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   7 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  27 
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  20 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 226 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  66 ++---
 drivers/gpu/drm/exynos/exynos_drm_plane.h  |   7 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 134 -
 drivers/gpu/drm/exynos/exynos_mixer.c  | 217 ++-
 include/video/samsung_fimd.h   |   5 +
 11 files changed, 337 insertions(+), 649 deletions(-)

-- 
2.1.0



[PATCH] drm/edid: set ELD for firmware and debugfs override EDIDs

2015-03-26 Thread Jani Nikula
If the user supplies EDID through firmware or debugfs override, the
driver callbacks are bypassed and the connector ELD does not get
updated, and audio fails. Set ELD for firmware and debugfs EDIDs too.

There should be no harm in gratuitously doing this for non HDMI/DP
connectors, as it's still up to the driver to use the ELD, if any.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691
Reported-by: Emil 
Reported-by: Rob Engle 
Tested-by: Jolan Luff 
Cc: stable at vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid_load.c| 1 +
 drivers/gpu/drm/drm_probe_helper.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 732cb6f8e653..4c0aa97aaf03 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -287,6 +287,7 @@ int drm_load_edid_firmware(struct drm_connector *connector)

drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
+   drm_edid_to_eld(connector, edid);
kfree(edid);

return ret;
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 6591d48c1b9d..3fee587bc284 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -174,6 +174,7 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
struct edid *edid = (struct edid *) 
connector->edid_blob_ptr->data;

count = drm_add_edid_modes(connector, edid);
+   drm_edid_to_eld(connector, edid);
} else
count = (*connector_funcs->get_modes)(connector);
}
-- 
2.1.4



[Intel-gfx] [PATCH] drm/edid: set ELD for firmware and debugfs override EDIDs

2015-03-26 Thread Daniel Vetter
On Thu, Mar 26, 2015 at 10:42:00AM +0200, Jani Nikula wrote:
> If the user supplies EDID through firmware or debugfs override, the
> driver callbacks are bypassed and the connector ELD does not get
> updated, and audio fails. Set ELD for firmware and debugfs EDIDs too.
> 
> There should be no harm in gratuitously doing this for non HDMI/DP
> connectors, as it's still up to the driver to use the ELD, if any.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691
> Reported-by: Emil 
> Reported-by: Rob Engle 
> Tested-by: Jolan Luff 
> Cc: stable at vger.kernel.org
> Signed-off-by: Jani Nikula 

Since it's harmless I wonder whether we shouldn't just do this in
drm_add_edid_modes unconditionally. But this looks like the right minimal
patch for -fixes, so Reviewed-by: Daniel Vetter 

Cheers, Daniel
> ---
>  drivers/gpu/drm/drm_edid_load.c| 1 +
>  drivers/gpu/drm/drm_probe_helper.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 732cb6f8e653..4c0aa97aaf03 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -287,6 +287,7 @@ int drm_load_edid_firmware(struct drm_connector 
> *connector)
>  
>   drm_mode_connector_update_edid_property(connector, edid);
>   ret = drm_add_edid_modes(connector, edid);
> + drm_edid_to_eld(connector, edid);
>   kfree(edid);
>  
>   return ret;
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 6591d48c1b9d..3fee587bc284 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -174,6 +174,7 @@ static int 
> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
>   struct edid *edid = (struct edid *) 
> connector->edid_blob_ptr->data;
>  
>   count = drm_add_edid_modes(connector, edid);
> + drm_edid_to_eld(connector, edid);
>   } else
>   count = (*connector_funcs->get_modes)(connector);
>   }
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread Michael S. Tsirkin
On Thu, Mar 26, 2015 at 09:42:47AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > And is it possible to use offset within BAR and/or memory BARs?
> > If yes I'd strongly prefer this.
> 
> What is the point?  Do you want place virtio regions and vga framebuffer
> in the same pci bar?  Why?  virtio is mmio and traps into qemu on
> access, whereas the vga framebuffer is memory-backed (with dirty
> tracking turned on).  Don't think this is a good idea, even though the
> memory api would probably allow to do this.
> 
> cheers,
>   Gerd

Absolutely, it's pretty common to mix regions in a BAR.
For example, we have virtio kick (ioeventfd backed,
handled in kernel) in same BAR as common and device
specific configuration.

We did the same thing you are now doing with the
virtio BAR, and now we have to maintain two code
bases, virtio pci config was designed to be future proof
so why not use it?

This is mostly just making sure we don't paint ourselves into a corner.

-- 
MST


[PATCH] xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic

2015-03-26 Thread ran...@sibernet.com

>
>> Alternatively can we:
>>  (1) move the wrapper to xf86drmMode.h itself, or
>>  (2) move this inline helper function out of xf86drmMode.h and into
>> the two libdrm tests that use it (or a shared test helper .h [0])
>>  (3) remove the inline and make drm_property_type_is a non-inline
>> function in xf86drmMode.c
>>
>> [0] I think Thierry already has a patch set that rearranges the tests
>> to use some shared headers.  Perhaps this will work well once his set
>> lands.
>>
> Fwiw I would opt for 1 or 3 (leaning towards 1), as 2 might lead to:
> - Everyone coming up with their own "helper", or
> - Ignoring DRM_MODE_PROP_EXTENDED_TYPE checking
> drmModePropertyPtr::flags, thus causing all sorts of chaos.
>
>
> Randy, Niveditha, Stuart,
>
> Does the compiler(s) used to build libdrm and friends support __inline ?

   It should.  I can't be 100% sure as there was just recently a new 
compiler release, but I would also suspect if this support was broken or 
dropped, then lots of stuff would break.


   Cheers!

 Randy


Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

2015-03-26 Thread ran...@sibernet.com
>
> Was honestly hoping that patch #1 is not required as:
> - Getting the drm.h header in sync with the kernel will be annoying.

   Indeed.

   I have a version of drm.h that works with Solaris and *should* still 
work with all other consumers, but as I still have a ways to get fully to 
speed, am hesitant to suggest a patch (are there other issues I have yet 
to discover).

> - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
> cruft for which, I would like to think, there are no more users.
>
> Obviously the latter can be confirmed by Randy and friends.

   I'm somewhat confused by this statement, as I still see the use of 
struct drm_map, as is it's usage in the Solaris ports of drm.  Am I 
missing something (like I said, I still have a ways to go to get to any 
decent level of contribution)?

   Cheers!

 Randy


[PATCH] Add virtio gpu driver.

2015-03-26 Thread Daniel Vetter
On Wed, Mar 25, 2015 at 03:53:09PM +0100, Gerd Hoffmann wrote:
> > > Signed-off-by: Dave Airlie 
> > > Signed-off-by: Gerd Hoffmann 
> > 
> > Standard request from my side for new drm drivers (especially if they're
> > this simple): Can you please update the drivers to latest drm internal
> > interfaces, i.e. using universal planes and atomic?
> 
> Have a docs / sample code pointer for me?

Picking any of the recently converted drivers or recently merged atomic
drivers should be fairly informative. Overall conversion procedure is
detailed in

http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html

And ofc there's the kerneldoc stuff in the drm docbook. If you have
questions probably best to ask them in #dri-devel irc, most of the people
who've done atomic conversions hang out there and can help out.

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


[virtio-dev] Re: [PATCH] Add virtio gpu driver.

2015-03-26 Thread Gerd Hoffmann
  Hi,

> And is it possible to use offset within BAR and/or memory BARs?
> If yes I'd strongly prefer this.

What is the point?  Do you want place virtio regions and vga framebuffer
in the same pci bar?  Why?  virtio is mmio and traps into qemu on
access, whereas the vga framebuffer is memory-backed (with dirty
tracking turned on).  Don't think this is a good idea, even though the
memory api would probably allow to do this.

cheers,
  Gerd




[PATCH] Add virtio gpu driver.

2015-03-26 Thread Michael S. Tsirkin
On Thu, Mar 26, 2015 at 08:12:39AM +0100, Gerd Hoffmann wrote:
> On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> > On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > BTW can we teach virtio-gpu to look for framebuffer using
> > > > virtio pci caps?
> > > 
> > > The virtio-gpu driver doesn't matter much here, it doesn't use it
> > > anyway.
> > > 
> > > >  Or are there limitations such as only
> > > > using IO port BARs, or compatibility with
> > > > BIOS code etc that limit us to specific BARs anyway?
> > > 
> > > Yes, vgabios code needs to know.  Currently it has bar #2 for the vga
> > > framebuffer bar hardcoded.  It's 16bit code.  I don't feel like making
> > > the probing more complicated ...
> > > 
> > > cheers,
> > >   Gerd
> > 
> > OK - you are saying all VGA cards use bar #2 for this
> > functionality, so we are just following
> > established practice here?
> 
> vgabios checks pci ids to figure.  qxl+stdvga use bar #0, vmware-vga bar
> #1, virtio-vga bar #2.
> 
> cheers,
>   Gerd
> 

And is it possible to use offset within BAR and/or memory BARs?
If yes I'd strongly prefer this.
As for writing 16 bit code, I need to do this for virtio scsi/blk
anyway, so we'll be able to share code.

-- 
MST


[git pull] drm urgent fix

2015-03-26 Thread Daniel Vetter
On Thu, Mar 26, 2015 at 4:29 AM, Dave Airlie  wrote:
> I've pushed a drm-fixes-staging branch that backport's Daniel's
> drm-next fix from 9 hours ago,
>
> However it isn't tested yet, so if you want to give it a whirl grab it.
>
> Hopefully when Daniel comes on line he can provide assurance that my
> fix is a correct backport.

Your missing the backport of

commit fb9981aa675eb7b398849915364916fd98833cfa
Author: Damien Lespiau 
Date:   Thu Feb 5 19:24:25 2015 +

drm/i915: Fix atomic state when reusing the firmware fb

My manual backport is here

http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg854137.html

The backport of the other patch you have in -staging looks fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[Bug 80691] HDMI audio stops working when drm_kms_helper edid overwrite in place

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=80691

--- Comment #5 from Jani Nikula  ---
(In reply to Alex Deucher from comment #4)
> The driver caches a copy of the edid in the driver connector structure
> (radeon_connector->edid) when it it reads the edid from the monitor via the
> get_modes() or detect() connector callbacks.  When you provide a user
> supplied edid, the driver's copy never gets updated since no additional
> driver callbacks are called.  It should be handled properly on my 3.17-wip
> branch:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-wip

Alex, did not look at what you did there, but there's no confirmation from the
reporters either. I submitted [1] to fix bug 82349, maybe that's relevant for
you too?

[1] http://patchwork.freedesktop.org/patch/45675/

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


[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89746

--- Comment #9 from Michel Dänzer  ---
(In reply to giuseppe from comment #8)
> Radeonsi  bug attachment

Is that from running with the patch applied?

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


[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion

2015-03-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89746

--- Comment #8 from giuseppe  ---
Created attachment 114641
  --> https://bugs.freedesktop.org/attachment.cgi?id=114641&action=edit
Radeonsi  bug attachment

THis is the output when I ran:

R600_DEBUG=ps,vs,gs ./genymotion

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


[PATCH] Add virtio gpu driver.

2015-03-26 Thread Gerd Hoffmann
On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > BTW can we teach virtio-gpu to look for framebuffer using
> > > virtio pci caps?
> > 
> > The virtio-gpu driver doesn't matter much here, it doesn't use it
> > anyway.
> > 
> > >  Or are there limitations such as only
> > > using IO port BARs, or compatibility with
> > > BIOS code etc that limit us to specific BARs anyway?
> > 
> > Yes, vgabios code needs to know.  Currently it has bar #2 for the vga
> > framebuffer bar hardcoded.  It's 16bit code.  I don't feel like making
> > the probing more complicated ...
> > 
> > cheers,
> >   Gerd
> 
> OK - you are saying all VGA cards use bar #2 for this
> functionality, so we are just following
> established practice here?

vgabios checks pci ids to figure.  qxl+stdvga use bar #0, vmware-vga bar
#1, virtio-vga bar #2.

cheers,
  Gerd




  1   2   >