[tip:perf/urgent] perf trace: Use the ptr->name beautifier as default for "filename" args

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  12f3ca4fc8e27aa602c9c3c717d755b1e8f7fd47
Gitweb: http://git.kernel.org/tip/12f3ca4fc8e27aa602c9c3c717d755b1e8f7fd47
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 23 May 2016 16:37:55 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 16:41:00 -0300

perf trace: Use the ptr->name beautifier as default for "filename" args

Auto-attach the ptr->name beautifier to syscall args "filename", "path"
and "pathname" if they are of type "const char *".

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-jxii4qmcgoppftv0zdvml...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 120 -
 1 file changed, 43 insertions(+), 77 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 181f69c..5c50fe7 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -576,44 +576,36 @@ static struct syscall_fmt {
bool   hexret;
 } syscall_fmts[] = {
{ .name = "access", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */
-[1] = SCA_ACCMODE,  /* mode */ }, },
+ .arg_scnprintf = { [1] = SCA_ACCMODE,  /* mode */ }, },
{ .name = "arch_prctl", .errmsg = true, .alias = "prctl", },
{ .name = "bpf",.errmsg = true, STRARRAY(0, cmd, bpf_cmd), 
},
{ .name = "brk",.hexret = true,
  .arg_scnprintf = { [0] = SCA_HEX, /* brk */ }, },
-   { .name = "chdir",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */ }, },
-   { .name = "chmod",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */ }, },
-   { .name = "chroot", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */ }, },
+   { .name = "chdir",  .errmsg = true, },
+   { .name = "chmod",  .errmsg = true, },
+   { .name = "chroot", .errmsg = true, },
{ .name = "clock_gettime",  .errmsg = true, STRARRAY(0, clk_id, 
clockid), },
{ .name = "clone",  .errpid = true, },
{ .name = "close",  .errmsg = true,
  .arg_scnprintf = { [0] = SCA_CLOSE_FD, /* fd */ }, },
{ .name = "connect",.errmsg = true, },
-   { .name = "creat",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* pathname */ }, },
+   { .name = "creat",  .errmsg = true, },
{ .name = "dup",.errmsg = true, },
{ .name = "dup2",   .errmsg = true, },
{ .name = "dup3",   .errmsg = true, },
{ .name = "epoll_ctl",  .errmsg = true, STRARRAY(1, op, 
epoll_ctl_ops), },
{ .name = "eventfd2",   .errmsg = true,
  .arg_scnprintf = { [1] = SCA_EFD_FLAGS, /* flags */ }, },
-   { .name = "faccessat",  .errmsg = true,
- .arg_scnprintf = { [1] = SCA_FILENAME, /* filename */ }, },
+   { .name = "faccessat",  .errmsg = true, },
{ .name = "fadvise64",  .errmsg = true, },
{ .name = "fallocate",  .errmsg = true, },
{ .name = "fchdir", .errmsg = true, },
{ .name = "fchmod", .errmsg = true, },
{ .name = "fchmodat",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
-[1] = SCA_FILENAME, /* filename */ }, },
+ .arg_scnprintf = { [0] = SCA_FDAT, /* fd */ }, },
{ .name = "fchown", .errmsg = true, },
{ .name = "fchownat",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
-[1] = SCA_FILENAME, /* filename */ }, },
+ .arg_scnprintf = { [0] = SCA_FDAT, /* fd */ }, },
{ .name = "fcntl",  .errmsg = true,
  .arg_scnprintf = { [1] = SCA_STRARRAY, /* cmd */ },
  .arg_parm  = { [1] = __fcntl_cmds, /* cmd */ }, },
@@ -622,16 +614,14 @@ static struct syscall_fmt {
  .arg_scnprintf = { [1] = SCA_FLOCK, /* cmd */ }, },
{ .name = "fsetxattr",  .errmsg = true, },
{ .name = "fstat",  .errmsg = true, .alias = "newfstat", },
-   { .name = "fstatat",.errmsg = true, .alias = "newfstatat",
- .arg_scnprintf = { [1] = SCA_FILENAME, /* filename */ }, },
+   { .name = "fstatat",.errmsg = true, .alias = "newfstatat", },
{ .name = "fstatfs",.errmsg = true, },
{ .name = "fsync",.errmsg = true, },
{ .name = "ftruncate", .errmsg = true, },
{ .name = "futex",  .errmsg = true,
  

[tip:perf/urgent] perf trace: Use the ptr->name beautifier as default for "filename" args

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  12f3ca4fc8e27aa602c9c3c717d755b1e8f7fd47
Gitweb: http://git.kernel.org/tip/12f3ca4fc8e27aa602c9c3c717d755b1e8f7fd47
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 23 May 2016 16:37:55 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 16:41:00 -0300

perf trace: Use the ptr->name beautifier as default for "filename" args

Auto-attach the ptr->name beautifier to syscall args "filename", "path"
and "pathname" if they are of type "const char *".

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-jxii4qmcgoppftv0zdvml...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 120 -
 1 file changed, 43 insertions(+), 77 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 181f69c..5c50fe7 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -576,44 +576,36 @@ static struct syscall_fmt {
bool   hexret;
 } syscall_fmts[] = {
{ .name = "access", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */
-[1] = SCA_ACCMODE,  /* mode */ }, },
+ .arg_scnprintf = { [1] = SCA_ACCMODE,  /* mode */ }, },
{ .name = "arch_prctl", .errmsg = true, .alias = "prctl", },
{ .name = "bpf",.errmsg = true, STRARRAY(0, cmd, bpf_cmd), 
},
{ .name = "brk",.hexret = true,
  .arg_scnprintf = { [0] = SCA_HEX, /* brk */ }, },
-   { .name = "chdir",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */ }, },
-   { .name = "chmod",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */ }, },
-   { .name = "chroot", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* filename */ }, },
+   { .name = "chdir",  .errmsg = true, },
+   { .name = "chmod",  .errmsg = true, },
+   { .name = "chroot", .errmsg = true, },
{ .name = "clock_gettime",  .errmsg = true, STRARRAY(0, clk_id, 
clockid), },
{ .name = "clone",  .errpid = true, },
{ .name = "close",  .errmsg = true,
  .arg_scnprintf = { [0] = SCA_CLOSE_FD, /* fd */ }, },
{ .name = "connect",.errmsg = true, },
-   { .name = "creat",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FILENAME, /* pathname */ }, },
+   { .name = "creat",  .errmsg = true, },
{ .name = "dup",.errmsg = true, },
{ .name = "dup2",   .errmsg = true, },
{ .name = "dup3",   .errmsg = true, },
{ .name = "epoll_ctl",  .errmsg = true, STRARRAY(1, op, 
epoll_ctl_ops), },
{ .name = "eventfd2",   .errmsg = true,
  .arg_scnprintf = { [1] = SCA_EFD_FLAGS, /* flags */ }, },
-   { .name = "faccessat",  .errmsg = true,
- .arg_scnprintf = { [1] = SCA_FILENAME, /* filename */ }, },
+   { .name = "faccessat",  .errmsg = true, },
{ .name = "fadvise64",  .errmsg = true, },
{ .name = "fallocate",  .errmsg = true, },
{ .name = "fchdir", .errmsg = true, },
{ .name = "fchmod", .errmsg = true, },
{ .name = "fchmodat",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
-[1] = SCA_FILENAME, /* filename */ }, },
+ .arg_scnprintf = { [0] = SCA_FDAT, /* fd */ }, },
{ .name = "fchown", .errmsg = true, },
{ .name = "fchownat",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
-[1] = SCA_FILENAME, /* filename */ }, },
+ .arg_scnprintf = { [0] = SCA_FDAT, /* fd */ }, },
{ .name = "fcntl",  .errmsg = true,
  .arg_scnprintf = { [1] = SCA_STRARRAY, /* cmd */ },
  .arg_parm  = { [1] = __fcntl_cmds, /* cmd */ }, },
@@ -622,16 +614,14 @@ static struct syscall_fmt {
  .arg_scnprintf = { [1] = SCA_FLOCK, /* cmd */ }, },
{ .name = "fsetxattr",  .errmsg = true, },
{ .name = "fstat",  .errmsg = true, .alias = "newfstat", },
-   { .name = "fstatat",.errmsg = true, .alias = "newfstatat",
- .arg_scnprintf = { [1] = SCA_FILENAME, /* filename */ }, },
+   { .name = "fstatat",.errmsg = true, .alias = "newfstatat", },
{ .name = "fstatfs",.errmsg = true, },
{ .name = "fsync",.errmsg = true, },
{ .name = "ftruncate", .errmsg = true, },
{ .name = "futex",  .errmsg = true,
  .arg_scnprintf = { [1] = SCA_FUTEX_OP, /* op */ }, },
{ .name = "futimesat", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
-  

[tip:perf/urgent] perf record: Read from backward ring buffer

[tip-bot for Wang Nan]

Commit-ID:  3a62a7b8200a177ad96161e4f2678514e6ee301e
Gitweb: http://git.kernel.org/tip/3a62a7b8200a177ad96161e4f2678514e6ee301e
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:41 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:48 -0300

perf record: Read from backward ring buffer

Introduce rb_find_range() to find start and end position from a backward
ring buffer.

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-5-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 52 +
 tools/perf/util/evlist.c|  1 +
 tools/perf/util/evlist.h|  1 +
 3 files changed, 54 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 73ce651..dc3fcb5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -83,6 +83,54 @@ static int process_synthesized_event(struct perf_tool *tool,
return record__write(rec, event, event->header.size);
 }
 
+static int
+backward_rb_find_range(void *buf, int mask, u64 head, u64 *start, u64 *end)
+{
+   struct perf_event_header *pheader;
+   u64 evt_head = head;
+   int size = mask + 1;
+
+   pr_debug2("backward_rb_find_range: buf=%p, head=%"PRIx64"\n", buf, 
head);
+   pheader = (struct perf_event_header *)(buf + (head & mask));
+   *start = head;
+   while (true) {
+   if (evt_head - head >= (unsigned int)size) {
+   pr_debug("Finshed reading backward ring buffer: 
rewind\n");
+   if (evt_head - head > (unsigned int)size)
+   evt_head -= pheader->size;
+   *end = evt_head;
+   return 0;
+   }
+
+   pheader = (struct perf_event_header *)(buf + (evt_head & mask));
+
+   if (pheader->size == 0) {
+   pr_debug("Finshed reading backward ring buffer: get 
start\n");
+   *end = evt_head;
+   return 0;
+   }
+
+   evt_head += pheader->size;
+   pr_debug3("move evt_head: %"PRIx64"\n", evt_head);
+   }
+   WARN_ONCE(1, "Shouldn't get here\n");
+   return -1;
+}
+
+static int
+rb_find_range(struct perf_evlist *evlist,
+ void *data, int mask, u64 head, u64 old,
+ u64 *start, u64 *end)
+{
+   if (!evlist->backward) {
+   *start = old;
+   *end = head;
+   return 0;
+   }
+
+   return backward_rb_find_range(data, mask, head, start, end);
+}
+
 static int record__mmap_read(struct record *rec, int idx)
 {
struct perf_mmap *md = >evlist->mmap[idx];
@@ -94,6 +142,10 @@ static int record__mmap_read(struct record *rec, int idx)
void *buf;
int rc = 0;
 
+   if (rb_find_range(rec->evlist, data, md->mask, head,
+ old, , ))
+   return -1;
+
if (start == end)
return 0;
 
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 904523a..e82ba90 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -44,6 +44,7 @@ void perf_evlist__init(struct perf_evlist *evlist, struct 
cpu_map *cpus,
perf_evlist__set_maps(evlist, cpus, threads);
fdarray__init(>pollfd, 64);
evlist->workload.pid = -1;
+   evlist->backward = false;
 }
 
 struct perf_evlist *perf_evlist__new(void)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 97090b7..d740fb8 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -44,6 +44,7 @@ struct perf_evlist {
bool overwrite;
bool enabled;
bool has_user_cpus;
+   bool backward;
size_t   mmap_len;
int  id_pos;
int  is_pos;

[tip:perf/urgent] perf record: Read from backward ring buffer

[tip-bot for Wang Nan]

Commit-ID:  3a62a7b8200a177ad96161e4f2678514e6ee301e
Gitweb: http://git.kernel.org/tip/3a62a7b8200a177ad96161e4f2678514e6ee301e
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:41 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:48 -0300

perf record: Read from backward ring buffer

Introduce rb_find_range() to find start and end position from a backward
ring buffer.

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-5-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 52 +
 tools/perf/util/evlist.c|  1 +
 tools/perf/util/evlist.h|  1 +
 3 files changed, 54 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 73ce651..dc3fcb5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -83,6 +83,54 @@ static int process_synthesized_event(struct perf_tool *tool,
return record__write(rec, event, event->header.size);
 }
 
+static int
+backward_rb_find_range(void *buf, int mask, u64 head, u64 *start, u64 *end)
+{
+   struct perf_event_header *pheader;
+   u64 evt_head = head;
+   int size = mask + 1;
+
+   pr_debug2("backward_rb_find_range: buf=%p, head=%"PRIx64"\n", buf, 
head);
+   pheader = (struct perf_event_header *)(buf + (head & mask));
+   *start = head;
+   while (true) {
+   if (evt_head - head >= (unsigned int)size) {
+   pr_debug("Finshed reading backward ring buffer: 
rewind\n");
+   if (evt_head - head > (unsigned int)size)
+   evt_head -= pheader->size;
+   *end = evt_head;
+   return 0;
+   }
+
+   pheader = (struct perf_event_header *)(buf + (evt_head & mask));
+
+   if (pheader->size == 0) {
+   pr_debug("Finshed reading backward ring buffer: get 
start\n");
+   *end = evt_head;
+   return 0;
+   }
+
+   evt_head += pheader->size;
+   pr_debug3("move evt_head: %"PRIx64"\n", evt_head);
+   }
+   WARN_ONCE(1, "Shouldn't get here\n");
+   return -1;
+}
+
+static int
+rb_find_range(struct perf_evlist *evlist,
+ void *data, int mask, u64 head, u64 old,
+ u64 *start, u64 *end)
+{
+   if (!evlist->backward) {
+   *start = old;
+   *end = head;
+   return 0;
+   }
+
+   return backward_rb_find_range(data, mask, head, start, end);
+}
+
 static int record__mmap_read(struct record *rec, int idx)
 {
struct perf_mmap *md = >evlist->mmap[idx];
@@ -94,6 +142,10 @@ static int record__mmap_read(struct record *rec, int idx)
void *buf;
int rc = 0;
 
+   if (rb_find_range(rec->evlist, data, md->mask, head,
+ old, , ))
+   return -1;
+
if (start == end)
return 0;
 
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 904523a..e82ba90 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -44,6 +44,7 @@ void perf_evlist__init(struct perf_evlist *evlist, struct 
cpu_map *cpus,
perf_evlist__set_maps(evlist, cpus, threads);
fdarray__init(>pollfd, 64);
evlist->workload.pid = -1;
+   evlist->backward = false;
 }
 
 struct perf_evlist *perf_evlist__new(void)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 97090b7..d740fb8 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -44,6 +44,7 @@ struct perf_evlist {
bool overwrite;
bool enabled;
bool has_user_cpus;
+   bool backward;
size_t   mmap_len;
int  id_pos;
int  is_pos;

[tip:perf/urgent] perf record: Rename variable to make code clear

[tip-bot for Wang Nan]

Commit-ID:  09fa4f401296f555afb6f2f4282717644d94722e
Gitweb: http://git.kernel.org/tip/09fa4f401296f555afb6f2f4282717644d94722e
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:40 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:47 -0300

perf record: Rename variable to make code clear

record__mmap_read() writes data from ring buffer into perf.data.  'head'
is maintained by the kernel, points to the last written record.
'old' is maintained by perf, points to the record read in previous
round. record__mmap_read() saves data from 'old' to 'head' to
perf.data.

The names of these variables are not very intutive. In addition,
when dealing with backward writing ring buffer, the md->prev pointer
should point to 'head' instead of the last byte it got.

Add 'start' and 'end' pointer to make code clear and set md->prev to
'head' instead of the moved 'old' pointer. This patch doesn't change
behavior since:

buf = [old & md->mask];
size = head - old;
old += size; <--- Here, old == head

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-4-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f302cc9..73ce651 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -88,17 +88,18 @@ static int record__mmap_read(struct record *rec, int idx)
struct perf_mmap *md = >evlist->mmap[idx];
u64 head = perf_mmap__read_head(md);
u64 old = md->prev;
+   u64 end = head, start = old;
unsigned char *data = md->base + page_size;
unsigned long size;
void *buf;
int rc = 0;
 
-   if (old == head)
+   if (start == end)
return 0;
 
rec->samples++;
 
-   size = head - old;
+   size = end - start;
if (size > (unsigned long)(md->mask) + 1) {
WARN_ONCE(1, "failed to keep up with mmap data. (warn only 
once)\n");
 
@@ -107,10 +108,10 @@ static int record__mmap_read(struct record *rec, int idx)
return 0;
}
 
-   if ((old & md->mask) + size != (head & md->mask)) {
-   buf = [old & md->mask];
-   size = md->mask + 1 - (old & md->mask);
-   old += size;
+   if ((start & md->mask) + size != (end & md->mask)) {
+   buf = [start & md->mask];
+   size = md->mask + 1 - (start & md->mask);
+   start += size;
 
if (record__write(rec, buf, size) < 0) {
rc = -1;
@@ -118,16 +119,16 @@ static int record__mmap_read(struct record *rec, int idx)
}
}
 
-   buf = [old & md->mask];
-   size = head - old;
-   old += size;
+   buf = [start & md->mask];
+   size = end - start;
+   start += size;
 
if (record__write(rec, buf, size) < 0) {
rc = -1;
goto out;
}
 
-   md->prev = old;
+   md->prev = head;
perf_evlist__mmap_consume(rec->evlist, idx);
 out:
return rc;

[tip:perf/urgent] perf evlist: Add API to pause/resume

[tip-bot for Wang Nan]

Commit-ID:  65aea2338765da1a58cc26eeb84d72308492ecb5
Gitweb: http://git.kernel.org/tip/65aea2338765da1a58cc26eeb84d72308492ecb5
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:38 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:00 -0300

perf evlist: Add API to pause/resume

perf_evlist__toggle_{pause,resume}() are introduced to pause/resume
events in an evlist. Utilize PERF_EVENT_IOC_PAUSE_OUTPUT ioctl.

Following commits use them to ensure overwrite ring buffer is paused
before reading.

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-2-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
[ Return -1, like all other ioctl() usage in evlist.c, rename 'pause'
  arg to avoid breaking the build on ubuntu 12.04 and other old systems ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 27 +++
 tools/perf/util/evlist.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 1a370db..904523a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -679,6 +679,33 @@ static struct perf_evsel *perf_evlist__event2evsel(struct 
perf_evlist *evlist,
return NULL;
 }
 
+static int perf_evlist__set_paused(struct perf_evlist *evlist, bool value)
+{
+   int i;
+
+   for (i = 0; i < evlist->nr_mmaps; i++) {
+   int fd = evlist->mmap[i].fd;
+   int err;
+
+   if (fd < 0)
+   continue;
+   err = ioctl(fd, PERF_EVENT_IOC_PAUSE_OUTPUT, value ? 1 : 0);
+   if (err)
+   return err;
+   }
+   return 0;
+}
+
+int perf_evlist__pause(struct perf_evlist *evlist)
+{
+   return perf_evlist__set_paused(evlist, true);
+}
+
+int perf_evlist__resume(struct perf_evlist *evlist)
+{
+   return perf_evlist__set_paused(evlist, false);
+}
+
 /* When check_messup is true, 'end' must points to a good entry */
 static union perf_event *
 perf_mmap__read(struct perf_mmap *md, bool check_messup, u64 start,
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 0d165b1..97090b7 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -136,6 +136,8 @@ void perf_evlist__mmap_read_catchup(struct perf_evlist 
*evlist, int idx);
 
 void perf_evlist__mmap_consume(struct perf_evlist *evlist, int idx);
 
+int perf_evlist__pause(struct perf_evlist *evlist);
+int perf_evlist__resume(struct perf_evlist *evlist);
 int perf_evlist__open(struct perf_evlist *evlist);
 void perf_evlist__close(struct perf_evlist *evlist);
 

[tip:perf/urgent] perf record: Prevent reading invalid data in record__mmap_read

[tip-bot for Wang Nan]

Commit-ID:  2d11c65071d489e20b3a811167507939dd8c2eac
Gitweb: http://git.kernel.org/tip/2d11c65071d489e20b3a811167507939dd8c2eac
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:39 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:46 -0300

perf record: Prevent reading invalid data in record__mmap_read

When record__mmap_read() requires data more than the size of ring
buffer, drop those data to avoid accessing invalid memory.

This can happen when reading from overwritable ring buffer, which
should be avoided. However, check this for robustness.

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-3-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f3679c4..f302cc9 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 struct record {
@@ -98,6 +99,13 @@ static int record__mmap_read(struct record *rec, int idx)
rec->samples++;
 
size = head - old;
+   if (size > (unsigned long)(md->mask) + 1) {
+   WARN_ONCE(1, "failed to keep up with mmap data. (warn only 
once)\n");
+
+   md->prev = head;
+   perf_evlist__mmap_consume(rec->evlist, idx);
+   return 0;
+   }
 
if ((old & md->mask) + size != (head & md->mask)) {
buf = [old & md->mask];

[tip:perf/urgent] perf record: Rename variable to make code clear

[tip-bot for Wang Nan]

Commit-ID:  09fa4f401296f555afb6f2f4282717644d94722e
Gitweb: http://git.kernel.org/tip/09fa4f401296f555afb6f2f4282717644d94722e
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:40 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:47 -0300

perf record: Rename variable to make code clear

record__mmap_read() writes data from ring buffer into perf.data.  'head'
is maintained by the kernel, points to the last written record.
'old' is maintained by perf, points to the record read in previous
round. record__mmap_read() saves data from 'old' to 'head' to
perf.data.

The names of these variables are not very intutive. In addition,
when dealing with backward writing ring buffer, the md->prev pointer
should point to 'head' instead of the last byte it got.

Add 'start' and 'end' pointer to make code clear and set md->prev to
'head' instead of the moved 'old' pointer. This patch doesn't change
behavior since:

buf = [old & md->mask];
size = head - old;
old += size; <--- Here, old == head

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-4-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f302cc9..73ce651 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -88,17 +88,18 @@ static int record__mmap_read(struct record *rec, int idx)
struct perf_mmap *md = >evlist->mmap[idx];
u64 head = perf_mmap__read_head(md);
u64 old = md->prev;
+   u64 end = head, start = old;
unsigned char *data = md->base + page_size;
unsigned long size;
void *buf;
int rc = 0;
 
-   if (old == head)
+   if (start == end)
return 0;
 
rec->samples++;
 
-   size = head - old;
+   size = end - start;
if (size > (unsigned long)(md->mask) + 1) {
WARN_ONCE(1, "failed to keep up with mmap data. (warn only 
once)\n");
 
@@ -107,10 +108,10 @@ static int record__mmap_read(struct record *rec, int idx)
return 0;
}
 
-   if ((old & md->mask) + size != (head & md->mask)) {
-   buf = [old & md->mask];
-   size = md->mask + 1 - (old & md->mask);
-   old += size;
+   if ((start & md->mask) + size != (end & md->mask)) {
+   buf = [start & md->mask];
+   size = md->mask + 1 - (start & md->mask);
+   start += size;
 
if (record__write(rec, buf, size) < 0) {
rc = -1;
@@ -118,16 +119,16 @@ static int record__mmap_read(struct record *rec, int idx)
}
}
 
-   buf = [old & md->mask];
-   size = head - old;
-   old += size;
+   buf = [start & md->mask];
+   size = end - start;
+   start += size;
 
if (record__write(rec, buf, size) < 0) {
rc = -1;
goto out;
}
 
-   md->prev = old;
+   md->prev = head;
perf_evlist__mmap_consume(rec->evlist, idx);
 out:
return rc;

[tip:perf/urgent] perf evlist: Add API to pause/resume

[tip-bot for Wang Nan]

Commit-ID:  65aea2338765da1a58cc26eeb84d72308492ecb5
Gitweb: http://git.kernel.org/tip/65aea2338765da1a58cc26eeb84d72308492ecb5
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:38 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:00 -0300

perf evlist: Add API to pause/resume

perf_evlist__toggle_{pause,resume}() are introduced to pause/resume
events in an evlist. Utilize PERF_EVENT_IOC_PAUSE_OUTPUT ioctl.

Following commits use them to ensure overwrite ring buffer is paused
before reading.

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-2-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
[ Return -1, like all other ioctl() usage in evlist.c, rename 'pause'
  arg to avoid breaking the build on ubuntu 12.04 and other old systems ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 27 +++
 tools/perf/util/evlist.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 1a370db..904523a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -679,6 +679,33 @@ static struct perf_evsel *perf_evlist__event2evsel(struct 
perf_evlist *evlist,
return NULL;
 }
 
+static int perf_evlist__set_paused(struct perf_evlist *evlist, bool value)
+{
+   int i;
+
+   for (i = 0; i < evlist->nr_mmaps; i++) {
+   int fd = evlist->mmap[i].fd;
+   int err;
+
+   if (fd < 0)
+   continue;
+   err = ioctl(fd, PERF_EVENT_IOC_PAUSE_OUTPUT, value ? 1 : 0);
+   if (err)
+   return err;
+   }
+   return 0;
+}
+
+int perf_evlist__pause(struct perf_evlist *evlist)
+{
+   return perf_evlist__set_paused(evlist, true);
+}
+
+int perf_evlist__resume(struct perf_evlist *evlist)
+{
+   return perf_evlist__set_paused(evlist, false);
+}
+
 /* When check_messup is true, 'end' must points to a good entry */
 static union perf_event *
 perf_mmap__read(struct perf_mmap *md, bool check_messup, u64 start,
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 0d165b1..97090b7 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -136,6 +136,8 @@ void perf_evlist__mmap_read_catchup(struct perf_evlist 
*evlist, int idx);
 
 void perf_evlist__mmap_consume(struct perf_evlist *evlist, int idx);
 
+int perf_evlist__pause(struct perf_evlist *evlist);
+int perf_evlist__resume(struct perf_evlist *evlist);
 int perf_evlist__open(struct perf_evlist *evlist);
 void perf_evlist__close(struct perf_evlist *evlist);
 

[tip:perf/urgent] perf record: Prevent reading invalid data in record__mmap_read

[tip-bot for Wang Nan]

Commit-ID:  2d11c65071d489e20b3a811167507939dd8c2eac
Gitweb: http://git.kernel.org/tip/2d11c65071d489e20b3a811167507939dd8c2eac
Author: Wang Nan 
AuthorDate: Mon, 23 May 2016 07:13:39 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 18:22:46 -0300

perf record: Prevent reading invalid data in record__mmap_read

When record__mmap_read() requires data more than the size of ring
buffer, drop those data to avoid accessing invalid memory.

This can happen when reading from overwritable ring buffer, which
should be avoided. However, check this for robustness.

Signed-off-by: Wang Nan 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463987628-163563-3-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f3679c4..f302cc9 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 struct record {
@@ -98,6 +99,13 @@ static int record__mmap_read(struct record *rec, int idx)
rec->samples++;
 
size = head - old;
+   if (size > (unsigned long)(md->mask) + 1) {
+   WARN_ONCE(1, "failed to keep up with mmap data. (warn only 
once)\n");
+
+   md->prev = head;
+   perf_evlist__mmap_consume(rec->evlist, idx);
+   return 0;
+   }
 
if ((old & md->mask) + size != (head & md->mask)) {
buf = [old & md->mask];

Re: [PATCH] Fix for hang of Ordered task in TCM

[Nicholas A. Bellinger]

Hi Bryant,

On Mon, 2016-05-23 at 19:17 -0400, Bryant G Ly wrote:
> Quoting "Nicholas A. Bellinger" :
> 
> 
> >
> > So AFAICT for delayed commands, the above patch ends up skipping these
> > three checks subsequently when doing __target_execute_cmd() directly
> > from target_restart_delayed_cmds(), no..?
> >
> > After pondering this some more, what about moving these checks into
> > __target_execute_cmd() to handle both target_core_transport.c cases
> > instead..?
> >
> > We'll also need a parameter for internal COMPARE_AND_WRITE usage
> > within compare_and_write_callback(), to bypass checks upon secondary
> > ->execute_cmd() WRITE payload submission after READ + COMPARE has
> > completed successfully.



> Looks good to me.

Thanks for the review!

> Nick just to let you know I've been working with  
> Mike on VSCSI Target Fabric and we need this patch in kernel 4.4 do
> you know of the process in getting that there?

So pending a bit more list feedback + testing across multiple fabric
drivers, it's been added for the moment to target-pending/queue as post
-rc1 material.

As it merged into target-pending/master next week, the extra stable CC'
can be added to be picked up for linux-4.4.y stable and friends.

Also AFAIK, we've not had reports of other SCSI host environments
triggering this bug, but it's still a good idea to consider it for
linux-3.x.y backport at some point as well.

[tip:perf/urgent] perf trace: Use the fd->name beautifier as default for "fd" args

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  b6565c908ad7eb28dfdda9578ec5a074e080cedc
Gitweb: http://git.kernel.org/tip/b6565c908ad7eb28dfdda9578ec5a074e080cedc
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 23 May 2016 12:59:53 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 16:41:00 -0300

perf trace: Use the fd->name beautifier as default for "fd" args

Noticed when the 'setsockopt' 'fd' arg wasn't being formatted via
the SCA_FD beautifier, so just remove the setting of "fd" args to
SCA_FD and do it when reading the syscall info, like we do for
args of type "pid_t", i.e. "fd" as the name should be enough as
the decision to use the SFA_FD beautifier. For odd cases we can
just do it explicitely.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-0qissgetiuqmqyj4b6anc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 132 +++--
 1 file changed, 54 insertions(+), 78 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 487c104..181f69c 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -595,65 +595,45 @@ static struct syscall_fmt {
{ .name = "connect",.errmsg = true, },
{ .name = "creat",  .errmsg = true,
  .arg_scnprintf = { [0] = SCA_FILENAME, /* pathname */ }, },
-   { .name = "dup",.errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "dup2",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "dup3",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+   { .name = "dup",.errmsg = true, },
+   { .name = "dup2",   .errmsg = true, },
+   { .name = "dup3",   .errmsg = true, },
{ .name = "epoll_ctl",  .errmsg = true, STRARRAY(1, op, 
epoll_ctl_ops), },
{ .name = "eventfd2",   .errmsg = true,
  .arg_scnprintf = { [1] = SCA_EFD_FLAGS, /* flags */ }, },
{ .name = "faccessat",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* dfd */
-[1] = SCA_FILENAME, /* filename */ }, },
-   { .name = "fadvise64",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fallocate",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fchdir", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fchmod", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+ .arg_scnprintf = { [1] = SCA_FILENAME, /* filename */ }, },
+   { .name = "fadvise64",  .errmsg = true, },
+   { .name = "fallocate",  .errmsg = true, },
+   { .name = "fchdir", .errmsg = true, },
+   { .name = "fchmod", .errmsg = true, },
{ .name = "fchmodat",   .errmsg = true,
  .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
 [1] = SCA_FILENAME, /* filename */ }, },
-   { .name = "fchown", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+   { .name = "fchown", .errmsg = true, },
{ .name = "fchownat",   .errmsg = true,
  .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
 [1] = SCA_FILENAME, /* filename */ }, },
{ .name = "fcntl",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */
-[1] = SCA_STRARRAY, /* cmd */ },
+ .arg_scnprintf = { [1] = SCA_STRARRAY, /* cmd */ },
  .arg_parm  = { [1] = __fcntl_cmds, /* cmd */ }, },
-   { .name = "fdatasync",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+   { .name = "fdatasync",  .errmsg = true, },
{ .name = "flock",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */
-[1] = SCA_FLOCK, /* cmd */ }, },
-   { .name = "fsetxattr",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fstat",  .errmsg = true, .alias = "newfstat",
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+ .arg_scnprintf = { [1] = SCA_FLOCK, /* cmd */ }, },
+   { .name = "fsetxattr",  .errmsg = true, },
+   { .name = "fstat",  .errmsg = true, .alias = "newfstat", },
{ .name = "fstatat",.errmsg = true, .alias = "newfstatat",
- .arg_scnprintf = { [0] = SCA_FDAT, /* dfd */
-[1] = SCA_FILENAME, 

Re: [PATCH] Fix for hang of Ordered task in TCM

[Nicholas A. Bellinger]

Hi Bryant,

On Mon, 2016-05-23 at 19:17 -0400, Bryant G Ly wrote:
> Quoting "Nicholas A. Bellinger" :
> 
> 
> >
> > So AFAICT for delayed commands, the above patch ends up skipping these
> > three checks subsequently when doing __target_execute_cmd() directly
> > from target_restart_delayed_cmds(), no..?
> >
> > After pondering this some more, what about moving these checks into
> > __target_execute_cmd() to handle both target_core_transport.c cases
> > instead..?
> >
> > We'll also need a parameter for internal COMPARE_AND_WRITE usage
> > within compare_and_write_callback(), to bypass checks upon secondary
> > ->execute_cmd() WRITE payload submission after READ + COMPARE has
> > completed successfully.



> Looks good to me.

Thanks for the review!

> Nick just to let you know I've been working with  
> Mike on VSCSI Target Fabric and we need this patch in kernel 4.4 do
> you know of the process in getting that there?

So pending a bit more list feedback + testing across multiple fabric
drivers, it's been added for the moment to target-pending/queue as post
-rc1 material.

As it merged into target-pending/master next week, the extra stable CC'
can be added to be picked up for linux-4.4.y stable and friends.

Also AFAIK, we've not had reports of other SCSI host environments
triggering this bug, but it's still a good idea to consider it for
linux-3.x.y backport at some point as well.

[tip:perf/urgent] perf trace: Use the fd->name beautifier as default for "fd" args

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  b6565c908ad7eb28dfdda9578ec5a074e080cedc
Gitweb: http://git.kernel.org/tip/b6565c908ad7eb28dfdda9578ec5a074e080cedc
Author: Arnaldo Carvalho de Melo 
AuthorDate: Mon, 23 May 2016 12:59:53 -0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 16:41:00 -0300

perf trace: Use the fd->name beautifier as default for "fd" args

Noticed when the 'setsockopt' 'fd' arg wasn't being formatted via
the SCA_FD beautifier, so just remove the setting of "fd" args to
SCA_FD and do it when reading the syscall info, like we do for
args of type "pid_t", i.e. "fd" as the name should be enough as
the decision to use the SFA_FD beautifier. For odd cases we can
just do it explicitely.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Milian Wolff 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-0qissgetiuqmqyj4b6anc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 132 +++--
 1 file changed, 54 insertions(+), 78 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 487c104..181f69c 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -595,65 +595,45 @@ static struct syscall_fmt {
{ .name = "connect",.errmsg = true, },
{ .name = "creat",  .errmsg = true,
  .arg_scnprintf = { [0] = SCA_FILENAME, /* pathname */ }, },
-   { .name = "dup",.errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "dup2",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "dup3",   .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+   { .name = "dup",.errmsg = true, },
+   { .name = "dup2",   .errmsg = true, },
+   { .name = "dup3",   .errmsg = true, },
{ .name = "epoll_ctl",  .errmsg = true, STRARRAY(1, op, 
epoll_ctl_ops), },
{ .name = "eventfd2",   .errmsg = true,
  .arg_scnprintf = { [1] = SCA_EFD_FLAGS, /* flags */ }, },
{ .name = "faccessat",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FDAT, /* dfd */
-[1] = SCA_FILENAME, /* filename */ }, },
-   { .name = "fadvise64",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fallocate",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fchdir", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fchmod", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+ .arg_scnprintf = { [1] = SCA_FILENAME, /* filename */ }, },
+   { .name = "fadvise64",  .errmsg = true, },
+   { .name = "fallocate",  .errmsg = true, },
+   { .name = "fchdir", .errmsg = true, },
+   { .name = "fchmod", .errmsg = true, },
{ .name = "fchmodat",   .errmsg = true,
  .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
 [1] = SCA_FILENAME, /* filename */ }, },
-   { .name = "fchown", .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+   { .name = "fchown", .errmsg = true, },
{ .name = "fchownat",   .errmsg = true,
  .arg_scnprintf = { [0] = SCA_FDAT, /* fd */
 [1] = SCA_FILENAME, /* filename */ }, },
{ .name = "fcntl",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */
-[1] = SCA_STRARRAY, /* cmd */ },
+ .arg_scnprintf = { [1] = SCA_STRARRAY, /* cmd */ },
  .arg_parm  = { [1] = __fcntl_cmds, /* cmd */ }, },
-   { .name = "fdatasync",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+   { .name = "fdatasync",  .errmsg = true, },
{ .name = "flock",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */
-[1] = SCA_FLOCK, /* cmd */ }, },
-   { .name = "fsetxattr",  .errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fstat",  .errmsg = true, .alias = "newfstat",
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
+ .arg_scnprintf = { [1] = SCA_FLOCK, /* cmd */ }, },
+   { .name = "fsetxattr",  .errmsg = true, },
+   { .name = "fstat",  .errmsg = true, .alias = "newfstat", },
{ .name = "fstatat",.errmsg = true, .alias = "newfstatat",
- .arg_scnprintf = { [0] = SCA_FDAT, /* dfd */
-[1] = SCA_FILENAME, /* filename */ }, },
-   { .name = "fstatfs",.errmsg = true,
- .arg_scnprintf = { [0] = SCA_FD, /* fd */ }, },
-   { .name = "fsync",.errmsg = 

[tip:perf/urgent] perf report: Add srcline_from/to branch sort keys

[tip-bot for Andi Kleen]

Commit-ID:  508be0dfe6287d4e6452f5a1dc08856df74cb217
Gitweb: http://git.kernel.org/tip/508be0dfe6287d4e6452f5a1dc08856df74cb217
Author: Andi Kleen 
AuthorDate: Fri, 20 May 2016 13:15:08 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 11:25:16 -0300

perf report: Add srcline_from/to branch sort keys

Add "srcline_from" and "srcline_to" branch sort keys that allow to show
the source lines of a branch.

That makes it much easier to track down where particular branches happen
in the program, for example to examine branch mispredictions, or to
associate it with cycle counts:

  % perf record -b -e cycles:p ./tcall
  % perf report --sort srcline_from,srcline_to,mispredict
  ...
15.10%  tcall.c:18   tcall.c:10   N
14.83%  tcall.c:11   tcall.c:5N
14.12%  tcall.c:7tcall.c:12   N
14.04%  tcall.c:12   tcall.c:5N
12.42%  tcall.c:17   tcall.c:18   N
12.39%  tcall.c:7tcall.c:13   N
12.27%  tcall.c:13   tcall.c:17   N
  ...

  % perf report --sort srcline_from,srcline_to,cycles
  ...
17.12%  tcall.c:18   tcall.c:11   1
17.01%  tcall.c:12   tcall.c:61
16.98%  tcall.c:11   tcall.c:61
15.91%  tcall.c:17   tcall.c:18   1
 6.38%  tcall.c:7tcall.c:17   7
 4.80%  tcall.c:7tcall.c:12   8
 4.21%  tcall.c:7tcall.c:17   8
 2.67%  tcall.c:7tcall.c:12   7
 2.62%  tcall.c:7tcall.c:12   10
 2.10%  tcall.c:7tcall.c:17   9
 1.58%  tcall.c:7tcall.c:12   6
 1.44%  tcall.c:7tcall.c:12   5
 1.38%  tcall.c:7tcall.c:12   9
 1.06%  tcall.c:7tcall.c:17   13
 1.05%  tcall.c:7tcall.c:12   4
 1.01%  tcall.c:7tcall.c:17   6

Open issues:

- Some kernel symbols get misresolved.

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Link: 
http://lkml.kernel.org/r/1463775308-32748-1-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-report.txt |  3 +-
 tools/perf/util/hist.c   |  9 
 tools/perf/util/hist.h   |  2 +
 tools/perf/util/sort.c   | 84 
 tools/perf/util/sort.h   |  2 +
 tools/perf/util/symbol.h |  2 +
 6 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 496d42c..9cbddc2 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -103,12 +103,13 @@ OPTIONS
 
If --branch-stack option is used, following sort keys are also
available:
-   dso_from, dso_to, symbol_from, symbol_to, mispredict.
 
- dso_from: name of library or module branched from
- dso_to: name of library or module branched to
- symbol_from: name of function branched from
- symbol_to: name of function branched to
+   - srcline_from: source file and line branched from
+   - srcline_to: source file and line branched to
- mispredict: "N" for predicted branch, "Y" for mispredicted branch
- in_tx: branch in TSX transaction
- abort: TSX transaction abort.
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index cfab531..d1f19e0 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -117,6 +117,13 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
hists__new_col_len(hists, HISTC_SYMBOL_TO, symlen);
hists__set_unres_dso_col_len(hists, HISTC_DSO_TO);
}
+
+   if (h->branch_info->srcline_from)
+   hists__new_col_len(hists, HISTC_SRCLINE_FROM,
+   strlen(h->branch_info->srcline_from));
+   if (h->branch_info->srcline_to)
+   hists__new_col_len(hists, HISTC_SRCLINE_TO,
+   strlen(h->branch_info->srcline_to));
}
 
if (h->mem_info) {
@@ -1042,6 +1049,8 @@ void hist_entry__delete(struct hist_entry *he)
if (he->branch_info) {
map__zput(he->branch_info->from.map);
map__zput(he->branch_info->to.map);
+   free_srcline(he->branch_info->srcline_from);
+   free_srcline(he->branch_info->srcline_to);
zfree(>branch_info);
}
 
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 0f84bfb..7b54ccf 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -52,6 +52,8 @@ enum hist_column {
HISTC_MEM_IADDR_SYMBOL,

[tip:perf/urgent] perf report: Add srcline_from/to branch sort keys

[tip-bot for Andi Kleen]

Commit-ID:  508be0dfe6287d4e6452f5a1dc08856df74cb217
Gitweb: http://git.kernel.org/tip/508be0dfe6287d4e6452f5a1dc08856df74cb217
Author: Andi Kleen 
AuthorDate: Fri, 20 May 2016 13:15:08 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 23 May 2016 11:25:16 -0300

perf report: Add srcline_from/to branch sort keys

Add "srcline_from" and "srcline_to" branch sort keys that allow to show
the source lines of a branch.

That makes it much easier to track down where particular branches happen
in the program, for example to examine branch mispredictions, or to
associate it with cycle counts:

  % perf record -b -e cycles:p ./tcall
  % perf report --sort srcline_from,srcline_to,mispredict
  ...
15.10%  tcall.c:18   tcall.c:10   N
14.83%  tcall.c:11   tcall.c:5N
14.12%  tcall.c:7tcall.c:12   N
14.04%  tcall.c:12   tcall.c:5N
12.42%  tcall.c:17   tcall.c:18   N
12.39%  tcall.c:7tcall.c:13   N
12.27%  tcall.c:13   tcall.c:17   N
  ...

  % perf report --sort srcline_from,srcline_to,cycles
  ...
17.12%  tcall.c:18   tcall.c:11   1
17.01%  tcall.c:12   tcall.c:61
16.98%  tcall.c:11   tcall.c:61
15.91%  tcall.c:17   tcall.c:18   1
 6.38%  tcall.c:7tcall.c:17   7
 4.80%  tcall.c:7tcall.c:12   8
 4.21%  tcall.c:7tcall.c:17   8
 2.67%  tcall.c:7tcall.c:12   7
 2.62%  tcall.c:7tcall.c:12   10
 2.10%  tcall.c:7tcall.c:17   9
 1.58%  tcall.c:7tcall.c:12   6
 1.44%  tcall.c:7tcall.c:12   5
 1.38%  tcall.c:7tcall.c:12   9
 1.06%  tcall.c:7tcall.c:17   13
 1.05%  tcall.c:7tcall.c:12   4
 1.01%  tcall.c:7tcall.c:17   6

Open issues:

- Some kernel symbols get misresolved.

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Link: 
http://lkml.kernel.org/r/1463775308-32748-1-git-send-email-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-report.txt |  3 +-
 tools/perf/util/hist.c   |  9 
 tools/perf/util/hist.h   |  2 +
 tools/perf/util/sort.c   | 84 
 tools/perf/util/sort.h   |  2 +
 tools/perf/util/symbol.h |  2 +
 6 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index 496d42c..9cbddc2 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -103,12 +103,13 @@ OPTIONS
 
If --branch-stack option is used, following sort keys are also
available:
-   dso_from, dso_to, symbol_from, symbol_to, mispredict.
 
- dso_from: name of library or module branched from
- dso_to: name of library or module branched to
- symbol_from: name of function branched from
- symbol_to: name of function branched to
+   - srcline_from: source file and line branched from
+   - srcline_to: source file and line branched to
- mispredict: "N" for predicted branch, "Y" for mispredicted branch
- in_tx: branch in TSX transaction
- abort: TSX transaction abort.
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index cfab531..d1f19e0 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -117,6 +117,13 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
hists__new_col_len(hists, HISTC_SYMBOL_TO, symlen);
hists__set_unres_dso_col_len(hists, HISTC_DSO_TO);
}
+
+   if (h->branch_info->srcline_from)
+   hists__new_col_len(hists, HISTC_SRCLINE_FROM,
+   strlen(h->branch_info->srcline_from));
+   if (h->branch_info->srcline_to)
+   hists__new_col_len(hists, HISTC_SRCLINE_TO,
+   strlen(h->branch_info->srcline_to));
}
 
if (h->mem_info) {
@@ -1042,6 +1049,8 @@ void hist_entry__delete(struct hist_entry *he)
if (he->branch_info) {
map__zput(he->branch_info->from.map);
map__zput(he->branch_info->to.map);
+   free_srcline(he->branch_info->srcline_from);
+   free_srcline(he->branch_info->srcline_to);
zfree(>branch_info);
}
 
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 0f84bfb..7b54ccf 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -52,6 +52,8 @@ enum hist_column {
HISTC_MEM_IADDR_SYMBOL,
HISTC_TRANSACTION,
HISTC_CYCLES,
+   HISTC_SRCLINE_FROM,
+   HISTC_SRCLINE_TO,
HISTC_TRACE,
 

[tip:perf/urgent] perf evsel: Add overwrite attribute and check write_backward

[tip-bot for Wang Nan]

Commit-ID:  b90dc17a5d14a881f9bb3b58edb3d71075d58afb
Gitweb: http://git.kernel.org/tip/b90dc17a5d14a881f9bb3b58edb3d71075d58afb
Author: Wang Nan 
AuthorDate: Fri, 20 May 2016 16:38:23 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Fri, 20 May 2016 14:54:23 -0300

perf evsel: Add overwrite attribute and check write_backward

Add 'overwrite' attribute to evsel to mark whether this event is
overwritable. The following commits will support syntax like:

  # perf record -e cycles/overwrite/ ...

An overwritable evsel requires kernel support for the
perf_event_attr.write_backward ring buffer feature.

Add it to perf_missing_feature.

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463762315-155689-2-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 13 +
 tools/perf/util/evsel.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 964c7c3..02c177d 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -37,6 +37,7 @@ static struct {
bool clockid;
bool clockid_wrong;
bool lbr_flags;
+   bool write_backward;
 } perf_missing_features;
 
 static clockid_t clockid;
@@ -1376,6 +1377,8 @@ fallback_missing_features:
if (perf_missing_features.lbr_flags)
evsel->attr.branch_sample_type &= ~(PERF_SAMPLE_BRANCH_NO_FLAGS 
|
 PERF_SAMPLE_BRANCH_NO_CYCLES);
+   if (perf_missing_features.write_backward)
+   evsel->attr.write_backward = false;
 retry_sample_id:
if (perf_missing_features.sample_id_all)
evsel->attr.sample_id_all = 0;
@@ -1438,6 +1441,12 @@ retry_open:
err = -EINVAL;
goto out_close;
}
+
+   if (evsel->overwrite &&
+   perf_missing_features.write_backward) {
+   err = -EINVAL;
+   goto out_close;
+   }
}
}
 
@@ -1500,6 +1509,10 @@ try_fallback:
  PERF_SAMPLE_BRANCH_NO_FLAGS))) {
perf_missing_features.lbr_flags = true;
goto fallback_missing_features;
+   } else if (!perf_missing_features.write_backward &&
+   evsel->attr.write_backward) {
+   perf_missing_features.write_backward = true;
+   goto fallback_missing_features;
}
 
 out_close:
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 8a644fe..c1f1015 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -112,6 +112,7 @@ struct perf_evsel {
booltracking;
boolper_pkg;
boolprecise_max;
+   booloverwrite;
/* parse modifier helper */
int exclude_GH;
int nr_members;

[tip:perf/urgent] perf evsel: Add overwrite attribute and check write_backward

[tip-bot for Wang Nan]

Commit-ID:  b90dc17a5d14a881f9bb3b58edb3d71075d58afb
Gitweb: http://git.kernel.org/tip/b90dc17a5d14a881f9bb3b58edb3d71075d58afb
Author: Wang Nan 
AuthorDate: Fri, 20 May 2016 16:38:23 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Fri, 20 May 2016 14:54:23 -0300

perf evsel: Add overwrite attribute and check write_backward

Add 'overwrite' attribute to evsel to mark whether this event is
overwritable. The following commits will support syntax like:

  # perf record -e cycles/overwrite/ ...

An overwritable evsel requires kernel support for the
perf_event_attr.write_backward ring buffer feature.

Add it to perf_missing_feature.

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463762315-155689-2-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evsel.c | 13 +
 tools/perf/util/evsel.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 964c7c3..02c177d 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -37,6 +37,7 @@ static struct {
bool clockid;
bool clockid_wrong;
bool lbr_flags;
+   bool write_backward;
 } perf_missing_features;
 
 static clockid_t clockid;
@@ -1376,6 +1377,8 @@ fallback_missing_features:
if (perf_missing_features.lbr_flags)
evsel->attr.branch_sample_type &= ~(PERF_SAMPLE_BRANCH_NO_FLAGS 
|
 PERF_SAMPLE_BRANCH_NO_CYCLES);
+   if (perf_missing_features.write_backward)
+   evsel->attr.write_backward = false;
 retry_sample_id:
if (perf_missing_features.sample_id_all)
evsel->attr.sample_id_all = 0;
@@ -1438,6 +1441,12 @@ retry_open:
err = -EINVAL;
goto out_close;
}
+
+   if (evsel->overwrite &&
+   perf_missing_features.write_backward) {
+   err = -EINVAL;
+   goto out_close;
+   }
}
}
 
@@ -1500,6 +1509,10 @@ try_fallback:
  PERF_SAMPLE_BRANCH_NO_FLAGS))) {
perf_missing_features.lbr_flags = true;
goto fallback_missing_features;
+   } else if (!perf_missing_features.write_backward &&
+   evsel->attr.write_backward) {
+   perf_missing_features.write_backward = true;
+   goto fallback_missing_features;
}
 
 out_close:
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 8a644fe..c1f1015 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -112,6 +112,7 @@ struct perf_evsel {
booltracking;
boolper_pkg;
boolprecise_max;
+   booloverwrite;
/* parse modifier helper */
int exclude_GH;
int nr_members;

[tip:perf/urgent] perf evsel: Record fd into perf_mmap

[tip-bot for Wang Nan]

Commit-ID:  d4c6fb36ac2c82f8f0c05b04cf102dcdc2d5a14d
Gitweb: http://git.kernel.org/tip/d4c6fb36ac2c82f8f0c05b04cf102dcdc2d5a14d
Author: Wang Nan 
AuthorDate: Fri, 20 May 2016 16:38:24 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Fri, 20 May 2016 14:56:58 -0300

perf evsel: Record fd into perf_mmap

Add a fd field into struct perf_mmap so that perf can track the mmap fd.

This feature will be used for toggling overwrite ring buffers.

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463762315-155689-3-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 6 ++
 tools/perf/util/evlist.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index c4bfe11..1a370db 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -881,6 +881,7 @@ static void __perf_evlist__munmap(struct perf_evlist 
*evlist, int idx)
if (evlist->mmap[idx].base != NULL) {
munmap(evlist->mmap[idx].base, evlist->mmap_len);
evlist->mmap[idx].base = NULL;
+   evlist->mmap[idx].fd = -1;
atomic_set(>mmap[idx].refcnt, 0);
}
auxtrace_mmap__munmap(>mmap[idx].auxtrace_mmap);
@@ -901,10 +902,14 @@ void perf_evlist__munmap(struct perf_evlist *evlist)
 
 static int perf_evlist__alloc_mmap(struct perf_evlist *evlist)
 {
+   int i;
+
evlist->nr_mmaps = cpu_map__nr(evlist->cpus);
if (cpu_map__empty(evlist->cpus))
evlist->nr_mmaps = thread_map__nr(evlist->threads);
evlist->mmap = zalloc(evlist->nr_mmaps * sizeof(struct perf_mmap));
+   for (i = 0; i < evlist->nr_mmaps; i++)
+   evlist->mmap[i].fd = -1;
return evlist->mmap != NULL ? 0 : -ENOMEM;
 }
 
@@ -941,6 +946,7 @@ static int __perf_evlist__mmap(struct perf_evlist *evlist, 
int idx,
evlist->mmap[idx].base = NULL;
return -1;
}
+   evlist->mmap[idx].fd = fd;
 
if (auxtrace_mmap__mmap(>mmap[idx].auxtrace_mmap,
>auxtrace_mp, evlist->mmap[idx].base, fd))
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 85d1b598..0d165b1 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -28,6 +28,7 @@ struct record_opts;
 struct perf_mmap {
void *base;
int  mask;
+   int  fd;
atomic_t refcnt;
u64  prev;
struct auxtrace_mmap auxtrace_mmap;

[tip:perf/urgent] perf evsel: Record fd into perf_mmap

[tip-bot for Wang Nan]

Commit-ID:  d4c6fb36ac2c82f8f0c05b04cf102dcdc2d5a14d
Gitweb: http://git.kernel.org/tip/d4c6fb36ac2c82f8f0c05b04cf102dcdc2d5a14d
Author: Wang Nan 
AuthorDate: Fri, 20 May 2016 16:38:24 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Fri, 20 May 2016 14:56:58 -0300

perf evsel: Record fd into perf_mmap

Add a fd field into struct perf_mmap so that perf can track the mmap fd.

This feature will be used for toggling overwrite ring buffers.

Signed-off-by: Wang Nan 
Cc: He Kuang 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Zefan Li 
Cc: pi3or...@163.com
Link: 
http://lkml.kernel.org/r/1463762315-155689-3-git-send-email-wangn...@huawei.com
Signed-off-by: He Kuang 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 6 ++
 tools/perf/util/evlist.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index c4bfe11..1a370db 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -881,6 +881,7 @@ static void __perf_evlist__munmap(struct perf_evlist 
*evlist, int idx)
if (evlist->mmap[idx].base != NULL) {
munmap(evlist->mmap[idx].base, evlist->mmap_len);
evlist->mmap[idx].base = NULL;
+   evlist->mmap[idx].fd = -1;
atomic_set(>mmap[idx].refcnt, 0);
}
auxtrace_mmap__munmap(>mmap[idx].auxtrace_mmap);
@@ -901,10 +902,14 @@ void perf_evlist__munmap(struct perf_evlist *evlist)
 
 static int perf_evlist__alloc_mmap(struct perf_evlist *evlist)
 {
+   int i;
+
evlist->nr_mmaps = cpu_map__nr(evlist->cpus);
if (cpu_map__empty(evlist->cpus))
evlist->nr_mmaps = thread_map__nr(evlist->threads);
evlist->mmap = zalloc(evlist->nr_mmaps * sizeof(struct perf_mmap));
+   for (i = 0; i < evlist->nr_mmaps; i++)
+   evlist->mmap[i].fd = -1;
return evlist->mmap != NULL ? 0 : -ENOMEM;
 }
 
@@ -941,6 +946,7 @@ static int __perf_evlist__mmap(struct perf_evlist *evlist, 
int idx,
evlist->mmap[idx].base = NULL;
return -1;
}
+   evlist->mmap[idx].fd = fd;
 
if (auxtrace_mmap__mmap(>mmap[idx].auxtrace_mmap,
>auxtrace_mp, evlist->mmap[idx].base, fd))
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 85d1b598..0d165b1 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -28,6 +28,7 @@ struct record_opts;
 struct perf_mmap {
void *base;
int  mask;
+   int  fd;
atomic_t refcnt;
u64  prev;
struct auxtrace_mmap auxtrace_mmap;

Re: [GIT PULL 0/9] perf/core improvements

[Ingo Molnar]

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit 408cf677073a5d1a7343bc6430a7297ba7b280d4:
> 
>   Merge tag 'perf-core-for-mingo-20160520' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2016-05-20 19:37:43 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-20160523
> 
> for you to fetch changes up to 3a62a7b8200a177ad96161e4f2678514e6ee301e:
> 
>   perf record: Read from backward ring buffer (2016-05-23 18:22:48 -0300)
> 
> 
> perf/core improvements:
> 
> User visible:
> 
> - Add "srcline_from" and "srcline_to" branch sort keys to 'perf top' and
>   'perf report' (Andi Kleen)
> 
> Infrastructure:
> 
> - Make 'perf trace' auto-attach fd->name and ptr->name beautifiers based
>   on the name of syscall arguments, this way new syscalls that have
>   'const char * (path,pathname,filename)' will use the fd->name beautifier
>   (vfs_getname perf probe, if in place) and the 'fd->name' (vfs_getname
>   or via /proc/PID/fd/) (Arnaldo Carvalho de Melo)
> 
> - Infrastructure to read from a ring buffer in backward write mode (Wang Nan)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Andi Kleen (1):
>   perf report: Add srcline_from/to branch sort keys
> 
> Arnaldo Carvalho de Melo (2):
>   perf trace: Use the fd->name beautifier as default for "fd" args
>   perf trace: Use the ptr->name beautifier as default for "filename" args
> 
> Wang Nan (6):
>   perf evsel: Add overwrite attribute and check write_backward
>   perf evsel: Record fd into perf_mmap
>   perf evlist: Add API to pause/resume
>   perf record: Prevent reading invalid data in record__mmap_read
>   perf record: Rename variable to make code clear
>   perf record: Read from backward ring buffer
> 
>  tools/perf/Documentation/perf-report.txt |   3 +-
>  tools/perf/builtin-record.c  |  81 --
>  tools/perf/builtin-trace.c   | 248 
> ---
>  tools/perf/util/evlist.c |  34 +
>  tools/perf/util/evlist.h |   4 +
>  tools/perf/util/evsel.c  |  13 ++
>  tools/perf/util/evsel.h  |   1 +
>  tools/perf/util/hist.c   |   9 ++
>  tools/perf/util/hist.h   |   2 +
>  tools/perf/util/sort.c   |  84 +++
>  tools/perf/util/sort.h   |   2 +
>  tools/perf/util/symbol.h |   2 +
>  12 files changed, 319 insertions(+), 164 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: [GIT PULL 0/9] perf/core improvements

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit 408cf677073a5d1a7343bc6430a7297ba7b280d4:
> 
>   Merge tag 'perf-core-for-mingo-20160520' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2016-05-20 19:37:43 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-20160523
> 
> for you to fetch changes up to 3a62a7b8200a177ad96161e4f2678514e6ee301e:
> 
>   perf record: Read from backward ring buffer (2016-05-23 18:22:48 -0300)
> 
> 
> perf/core improvements:
> 
> User visible:
> 
> - Add "srcline_from" and "srcline_to" branch sort keys to 'perf top' and
>   'perf report' (Andi Kleen)
> 
> Infrastructure:
> 
> - Make 'perf trace' auto-attach fd->name and ptr->name beautifiers based
>   on the name of syscall arguments, this way new syscalls that have
>   'const char * (path,pathname,filename)' will use the fd->name beautifier
>   (vfs_getname perf probe, if in place) and the 'fd->name' (vfs_getname
>   or via /proc/PID/fd/) (Arnaldo Carvalho de Melo)
> 
> - Infrastructure to read from a ring buffer in backward write mode (Wang Nan)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Andi Kleen (1):
>   perf report: Add srcline_from/to branch sort keys
> 
> Arnaldo Carvalho de Melo (2):
>   perf trace: Use the fd->name beautifier as default for "fd" args
>   perf trace: Use the ptr->name beautifier as default for "filename" args
> 
> Wang Nan (6):
>   perf evsel: Add overwrite attribute and check write_backward
>   perf evsel: Record fd into perf_mmap
>   perf evlist: Add API to pause/resume
>   perf record: Prevent reading invalid data in record__mmap_read
>   perf record: Rename variable to make code clear
>   perf record: Read from backward ring buffer
> 
>  tools/perf/Documentation/perf-report.txt |   3 +-
>  tools/perf/builtin-record.c  |  81 --
>  tools/perf/builtin-trace.c   | 248 
> ---
>  tools/perf/util/evlist.c |  34 +
>  tools/perf/util/evlist.h |   4 +
>  tools/perf/util/evsel.c  |  13 ++
>  tools/perf/util/evsel.h  |   1 +
>  tools/perf/util/hist.c   |   9 ++
>  tools/perf/util/hist.h   |   2 +
>  tools/perf/util/sort.c   |  84 +++
>  tools/perf/util/sort.h   |   2 +
>  tools/perf/util/symbol.h |   2 +
>  12 files changed, 319 insertions(+), 164 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: [PATCH] powerpc: inline current_stack_pointer()

[Christophe Leroy]

Le 23/05/2016 à 22:22, Segher Boessenkool a écrit :

On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote:

+static inline unsigned long current_stack_pointer(void)
+{
+   register unsigned long *ptr asm("r1");
+
+   return *ptr;
+}

Register asm is only guaranteed to work as input to inline asm.  NAK.

Does it mean that the following declaration in 
arch/powerpc/include/asm/paca.h is wrong too ?


register struct paca_struct *local_paca asm("r13");

Christophe

Re: [PATCH] powerpc: inline current_stack_pointer()

[Christophe Leroy]

Le 23/05/2016 à 22:22, Segher Boessenkool a écrit :

On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote:

+static inline unsigned long current_stack_pointer(void)
+{
+   register unsigned long *ptr asm("r1");
+
+   return *ptr;
+}

Register asm is only guaranteed to work as input to inline asm.  NAK.

Does it mean that the following declaration in 
arch/powerpc/include/asm/paca.h is wrong too ?


register struct paca_struct *local_paca asm("r13");

Christophe

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

[Joonsoo Kim]

On Fri, May 20, 2016 at 10:00:06AM -0700, Shi, Yang wrote:
> On 5/19/2016 7:40 PM, Joonsoo Kim wrote:
> >2016-05-20 2:18 GMT+09:00 Shi, Yang :
> >>On 5/18/2016 5:28 PM, Joonsoo Kim wrote:
> >>>
> >>>Vlastiml, thanks for ccing me on original bug report.
> >>>
> >>>On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote:
> 
> When enabling the below kernel configs:
> 
> CONFIG_DEFERRED_STRUCT_PAGE_INIT
> CONFIG_DEBUG_PAGEALLOC
> CONFIG_PAGE_EXTENSION
> CONFIG_DEBUG_VM
> 
> kernel bootup may fail due to the following oops:
> 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: [] free_pcppages_bulk+0x2d2/0x8d0
> PGD 0
> Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 11 PID: 106 Comm: pgdatinit1 Not tainted 4.6.0-rc5-next-20160427 #26
> Hardware name: Intel Corporation S5520HC/S5520HC, BIOS
> S5500.86B.01.10.0025.030220091519 03/02/2009
> task: 88017c080040 ti: 88017c084000 task.ti: 88017c084000
> RIP: 0010:[]  []
> free_pcppages_bulk+0x2d2/0x8d0
> RSP: :88017c087c48  EFLAGS: 00010046
> RAX:  RBX:  RCX: 0001
> RDX: 0980 RSI: 0080 RDI: 00660401
> RBP: 88017c087cd0 R08: 0401 R09: 0009
> R10: 88017c080040 R11: 000a R12: 0400
> R13: ea001981 R14: ea0019810040 R15: 88066cfe6080
> FS:  () GS:88066cd4()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 02406000 CR4: 06e0
> Stack:
>  88066cd5bbd8 88066cfe6640  
>  001f001f 88066cd5bbe8 ea001981 8118f53e
>  0009 0401 000a 0001
> Call Trace:
>  [] free_hot_cold_page+0x192/0x1d0
>  [] __free_pages+0x5c/0x90
>  [] __free_pages_boot_core+0x11a/0x14e
>  [] deferred_free_range+0x50/0x62
>  [] deferred_init_memmap+0x220/0x3c3
>  [] ? setup_per_cpu_pageset+0x35/0x35
>  [] kthread+0xf8/0x110
>  [] ret_from_fork+0x22/0x40
>  [] ? kthread_create_on_node+0x200/0x200
> Code: 49 89 d4 48 c1 e0 06 49 01 c5 e9 de fe ff ff 4c 89 f7 44 89 4d b8
> 4c 89 45 c0 44 89 5d c8 48 89 4d d0 e8 62 c7 07 00 48 8b 4d d0 <48> 8b 00 
> 44
> 8b 5d c8 4c 8b 45 c0 44 8b 4d b8 a8 02 0f 84 05 ff
> RIP  [] free_pcppages_bulk+0x2d2/0x8d0
>  RSP 
> CR2: 
> 
> The problem is lookup_page_ext() returns NULL then page_is_guard() tried
> to
> access it in page freeing.
> 
> page_is_guard() depends on PAGE_EXT_DEBUG_GUARD bit of page extension
> flag, but
> freeing page might reach here before the page_ext arrays are allocated
> when
> feeding a range of pages to the allocator for the first time during
> bootup or
> memory hotplug.
> >>>
> >>>
> >>>Patch itself looks find to me because I also found that this kind of
> >>>problem happens during memory hotplug. So, we need to fix more sites,
> >>>all callers of lookup_page_ext().
> >>
> >>
> >>Yes, I agree. I will come up with a patch or a couple of patches to check
> >>the return value of lookup_page_ext().
> >>
> >>>
> >>>But, I'd like to know how your problem occurs during bootup.
> >>>debug_guardpage_enabled() is turned to 'enable' after page_ext is
> >>>initialized. Before that, page_is_guard() unconditionally returns
> >>>false so I think that the problem what you mentioned can't happen.
> >>>
> >>>Could you check that when debug_guardpage_enabled() returns 'enable'
> >>>and init_section_page_ext() is called?
> >>
> >>
> >>I think the problem is I have CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled,
> >>which will defer some struct pages initialization to "pgdatinitX" kernel
> >>thread in page_alloc_init_late(). But, page_ext_init() is called before it.
> >>So, it leads debug_guardpage_enabled() return true, but page extension is
> >>not allocated yet for the struct pages initialized by "pgdatinitX".
> >
> >No. After page_ext_init(), it is ensured that all page extension is 
> >initialized.
> >
> >>It sounds page_ext_init() should be called after page_alloc_init_late(). Or
> >>it should be just incompatible with CONFIG_DEFERRED_STRUCT_PAGE_INIT.
> >>
> >>I will try to move the init call around.
> >
> >We need to investigate more. I guess that problem is introduced by
> >CONFIG_DEFERRED_STRUCT_PAGE_INIT. It makes pfn_to_nid() invalid
> >until page_alloc_init_late() is done. That is a big side-effect. If
> >there is pfn walker
> >and it uses pfn_to_nid() between memmap_init_zone() and 
> >page_alloc_init_late(),
> >it also has same problem. So, we need to think how to fix it more
> >carefully.
> 
> Thanks for the analysis. I think you are 

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

[Joonsoo Kim]

On Fri, May 20, 2016 at 10:00:06AM -0700, Shi, Yang wrote:
> On 5/19/2016 7:40 PM, Joonsoo Kim wrote:
> >2016-05-20 2:18 GMT+09:00 Shi, Yang :
> >>On 5/18/2016 5:28 PM, Joonsoo Kim wrote:
> >>>
> >>>Vlastiml, thanks for ccing me on original bug report.
> >>>
> >>>On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote:
> 
> When enabling the below kernel configs:
> 
> CONFIG_DEFERRED_STRUCT_PAGE_INIT
> CONFIG_DEBUG_PAGEALLOC
> CONFIG_PAGE_EXTENSION
> CONFIG_DEBUG_VM
> 
> kernel bootup may fail due to the following oops:
> 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: [] free_pcppages_bulk+0x2d2/0x8d0
> PGD 0
> Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 11 PID: 106 Comm: pgdatinit1 Not tainted 4.6.0-rc5-next-20160427 #26
> Hardware name: Intel Corporation S5520HC/S5520HC, BIOS
> S5500.86B.01.10.0025.030220091519 03/02/2009
> task: 88017c080040 ti: 88017c084000 task.ti: 88017c084000
> RIP: 0010:[]  []
> free_pcppages_bulk+0x2d2/0x8d0
> RSP: :88017c087c48  EFLAGS: 00010046
> RAX:  RBX:  RCX: 0001
> RDX: 0980 RSI: 0080 RDI: 00660401
> RBP: 88017c087cd0 R08: 0401 R09: 0009
> R10: 88017c080040 R11: 000a R12: 0400
> R13: ea001981 R14: ea0019810040 R15: 88066cfe6080
> FS:  () GS:88066cd4()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 02406000 CR4: 06e0
> Stack:
>  88066cd5bbd8 88066cfe6640  
>  001f001f 88066cd5bbe8 ea001981 8118f53e
>  0009 0401 000a 0001
> Call Trace:
>  [] free_hot_cold_page+0x192/0x1d0
>  [] __free_pages+0x5c/0x90
>  [] __free_pages_boot_core+0x11a/0x14e
>  [] deferred_free_range+0x50/0x62
>  [] deferred_init_memmap+0x220/0x3c3
>  [] ? setup_per_cpu_pageset+0x35/0x35
>  [] kthread+0xf8/0x110
>  [] ret_from_fork+0x22/0x40
>  [] ? kthread_create_on_node+0x200/0x200
> Code: 49 89 d4 48 c1 e0 06 49 01 c5 e9 de fe ff ff 4c 89 f7 44 89 4d b8
> 4c 89 45 c0 44 89 5d c8 48 89 4d d0 e8 62 c7 07 00 48 8b 4d d0 <48> 8b 00 
> 44
> 8b 5d c8 4c 8b 45 c0 44 8b 4d b8 a8 02 0f 84 05 ff
> RIP  [] free_pcppages_bulk+0x2d2/0x8d0
>  RSP 
> CR2: 
> 
> The problem is lookup_page_ext() returns NULL then page_is_guard() tried
> to
> access it in page freeing.
> 
> page_is_guard() depends on PAGE_EXT_DEBUG_GUARD bit of page extension
> flag, but
> freeing page might reach here before the page_ext arrays are allocated
> when
> feeding a range of pages to the allocator for the first time during
> bootup or
> memory hotplug.
> >>>
> >>>
> >>>Patch itself looks find to me because I also found that this kind of
> >>>problem happens during memory hotplug. So, we need to fix more sites,
> >>>all callers of lookup_page_ext().
> >>
> >>
> >>Yes, I agree. I will come up with a patch or a couple of patches to check
> >>the return value of lookup_page_ext().
> >>
> >>>
> >>>But, I'd like to know how your problem occurs during bootup.
> >>>debug_guardpage_enabled() is turned to 'enable' after page_ext is
> >>>initialized. Before that, page_is_guard() unconditionally returns
> >>>false so I think that the problem what you mentioned can't happen.
> >>>
> >>>Could you check that when debug_guardpage_enabled() returns 'enable'
> >>>and init_section_page_ext() is called?
> >>
> >>
> >>I think the problem is I have CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled,
> >>which will defer some struct pages initialization to "pgdatinitX" kernel
> >>thread in page_alloc_init_late(). But, page_ext_init() is called before it.
> >>So, it leads debug_guardpage_enabled() return true, but page extension is
> >>not allocated yet for the struct pages initialized by "pgdatinitX".
> >
> >No. After page_ext_init(), it is ensured that all page extension is 
> >initialized.
> >
> >>It sounds page_ext_init() should be called after page_alloc_init_late(). Or
> >>it should be just incompatible with CONFIG_DEFERRED_STRUCT_PAGE_INIT.
> >>
> >>I will try to move the init call around.
> >
> >We need to investigate more. I guess that problem is introduced by
> >CONFIG_DEFERRED_STRUCT_PAGE_INIT. It makes pfn_to_nid() invalid
> >until page_alloc_init_late() is done. That is a big side-effect. If
> >there is pfn walker
> >and it uses pfn_to_nid() between memmap_init_zone() and 
> >page_alloc_init_late(),
> >it also has same problem. So, we need to think how to fix it more
> >carefully.
> 
> Thanks for the analysis. I think you are correct. Since 

[PATCH v3] Axi-usb: Add support for 64-bit addressing.

[Nava kishore Manne]

This patch updates the driver to support 64-bit DMA addressing.

Signed-off-by: Nava kishore Manne 
---
Changes for v3:
-Added new compatable string for 5.00 IP version as suggested by
 Arnd Bergmann.
-Used write_fn() insted of lo_hi_writeq() as suggested by
 Arnd Bergmann.

Changes for v2:
-Added dma-ranges property in device tree as suggested by Arnd 
Bergmann.
-Modified the driver code based on the xlnx,addrwidth.

 .../devicetree/bindings/usb/udc-xilinx.txt | 21 +
 drivers/usb/gadget/udc/udc-xilinx.c| 53 --
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt 
b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
index 47b4e39..09df757 100644
--- a/Documentation/devicetree/bindings/usb/udc-xilinx.txt
+++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
@@ -1,18 +1,23 @@
 Xilinx USB2 device controller
 
 Required properties:
-- compatible   : Should be "xlnx,usb2-device-4.00.a"
+- compatible   : Should be "xlnx,usb2-device-4.00.a" or
+ "xlnx,usb2-device-5.00"
 - reg  : Physical base address and size of the USB2
  device registers map.
 - interrupts   : Should contain single irq line of USB2 device
  controller
 - xlnx,has-builtin-dma : if DMA is included
+- dma-ranges   : Should be as the following
+ 
+- xlnx,addrwidth   : Should be the dma addressing size in bits(ex: 64 bits)
 
 Example:
-   axi-usb2-device@42e0 {
-compatible = "xlnx,usb2-device-4.00.a";
-interrupts = <0x0 0x39 0x1>;
-reg = <0x42e0 0x1>;
-xlnx,has-builtin-dma;
-};
-
+   axi-usb2-device@42e0 {
+   compatible = "xlnx,usb2-device-4.00.a";
+   interrupts = <0x0 0x39 0x1>;
+   reg = <0x42e0 0x1>;
+   dma-ranges = <0x 0x 0x4000>;
+   xlnx,has-builtin-dma;
+   xlnx,addrwidth = <0x40>;
+   };
diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
b/drivers/usb/gadget/udc/udc-xilinx.c
index 1cbb0ac..112a6f3 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -47,6 +47,15 @@
 #define XUSB_DMA_LENGTH_OFFSET 0x0210  /* DMA Length Register */
 #define XUSB_DMA_STATUS_OFFSET 0x0214  /* DMA Status Register */
 
+/* DMA source Address Reg for LSB */
+#define XUSB_DMA_DSAR_ADDR_OFFSET_LSB   0x0308
+/* DMA source Address Reg for MSB */
+#define XUSB_DMA_DSAR_ADDR_OFFSET_MSB   0x030C
+/* DMA destination Addr Reg LSB */
+#define XUSB_DMA_DDAR_ADDR_OFFSET_LSB   0x0310
+/* DMA destination Addr Reg MSB */
+#define XUSB_DMA_DDAR_ADDR_OFFSET_MSB   0x0314
+
 /* Endpoint Configuration Space offsets */
 #define XUSB_EP_CFGSTATUS_OFFSET   0x00/* Endpoint Config Status  */
 #define XUSB_EP_BUF0COUNT_OFFSET   0x08/* Buffer 0 Count */
@@ -193,7 +202,7 @@ struct xusb_udc {
void __iomem *addr;
spinlock_t lock;
bool dma_enabled;
-
+   u32 dma_addrwidth;
unsigned int (*read_fn)(void __iomem *);
void (*write_fn)(void __iomem *, u32, u32);
 };
@@ -214,6 +223,20 @@ static const struct usb_endpoint_descriptor 
config_bulk_out_desc = {
.wMaxPacketSize = cpu_to_le16(EP0_MAX_PACKET),
 };
 
+/**
+ * xudc_write64 - write 64bit value to device registers
+ * @addr: base addr of device registers
+ * @offset: register offset
+ * @val: data to be written
+ **/
+static void xudc_write64(struct xusb_ep *ep, u32 offset, u64 val)
+{
+   struct xusb_udc *udc = ep->udc;
+
+   udc->write_fn(udc->addr, offset, lower_32_bits(val));
+   udc->write_fn(udc->addr, offset+0x04, upper_32_bits(val));
+}
+
 /**
  * xudc_write32 - little endian write to device registers
  * @addr: base addr of device registers
@@ -330,8 +353,13 @@ static int xudc_start_dma(struct xusb_ep *ep, dma_addr_t 
src,
 * destination registers and then set the length
 * into the DMA length register.
 */
-   udc->write_fn(udc->addr, XUSB_DMA_DSAR_ADDR_OFFSET, src);
-   udc->write_fn(udc->addr, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+   if (udc->dma_addrwidth > 32) {
+   xudc_write64(ep, XUSB_DMA_DSAR_ADDR_OFFSET_LSB, src);
+   xudc_write64(ep, XUSB_DMA_DDAR_ADDR_OFFSET_LSB, dst);
+   } else {
+   udc->write_fn(udc->addr, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+   udc->write_fn(udc->addr, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+   }
udc->write_fn(udc->addr, 

[PATCH v3] Axi-usb: Add support for 64-bit addressing.

[Nava kishore Manne]

This patch updates the driver to support 64-bit DMA addressing.

Signed-off-by: Nava kishore Manne 
---
Changes for v3:
-Added new compatable string for 5.00 IP version as suggested by
 Arnd Bergmann.
-Used write_fn() insted of lo_hi_writeq() as suggested by
 Arnd Bergmann.

Changes for v2:
-Added dma-ranges property in device tree as suggested by Arnd 
Bergmann.
-Modified the driver code based on the xlnx,addrwidth.

 .../devicetree/bindings/usb/udc-xilinx.txt | 21 +
 drivers/usb/gadget/udc/udc-xilinx.c| 53 --
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt 
b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
index 47b4e39..09df757 100644
--- a/Documentation/devicetree/bindings/usb/udc-xilinx.txt
+++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
@@ -1,18 +1,23 @@
 Xilinx USB2 device controller
 
 Required properties:
-- compatible   : Should be "xlnx,usb2-device-4.00.a"
+- compatible   : Should be "xlnx,usb2-device-4.00.a" or
+ "xlnx,usb2-device-5.00"
 - reg  : Physical base address and size of the USB2
  device registers map.
 - interrupts   : Should contain single irq line of USB2 device
  controller
 - xlnx,has-builtin-dma : if DMA is included
+- dma-ranges   : Should be as the following
+ 
+- xlnx,addrwidth   : Should be the dma addressing size in bits(ex: 64 bits)
 
 Example:
-   axi-usb2-device@42e0 {
-compatible = "xlnx,usb2-device-4.00.a";
-interrupts = <0x0 0x39 0x1>;
-reg = <0x42e0 0x1>;
-xlnx,has-builtin-dma;
-};
-
+   axi-usb2-device@42e0 {
+   compatible = "xlnx,usb2-device-4.00.a";
+   interrupts = <0x0 0x39 0x1>;
+   reg = <0x42e0 0x1>;
+   dma-ranges = <0x 0x 0x4000>;
+   xlnx,has-builtin-dma;
+   xlnx,addrwidth = <0x40>;
+   };
diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
b/drivers/usb/gadget/udc/udc-xilinx.c
index 1cbb0ac..112a6f3 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -47,6 +47,15 @@
 #define XUSB_DMA_LENGTH_OFFSET 0x0210  /* DMA Length Register */
 #define XUSB_DMA_STATUS_OFFSET 0x0214  /* DMA Status Register */
 
+/* DMA source Address Reg for LSB */
+#define XUSB_DMA_DSAR_ADDR_OFFSET_LSB   0x0308
+/* DMA source Address Reg for MSB */
+#define XUSB_DMA_DSAR_ADDR_OFFSET_MSB   0x030C
+/* DMA destination Addr Reg LSB */
+#define XUSB_DMA_DDAR_ADDR_OFFSET_LSB   0x0310
+/* DMA destination Addr Reg MSB */
+#define XUSB_DMA_DDAR_ADDR_OFFSET_MSB   0x0314
+
 /* Endpoint Configuration Space offsets */
 #define XUSB_EP_CFGSTATUS_OFFSET   0x00/* Endpoint Config Status  */
 #define XUSB_EP_BUF0COUNT_OFFSET   0x08/* Buffer 0 Count */
@@ -193,7 +202,7 @@ struct xusb_udc {
void __iomem *addr;
spinlock_t lock;
bool dma_enabled;
-
+   u32 dma_addrwidth;
unsigned int (*read_fn)(void __iomem *);
void (*write_fn)(void __iomem *, u32, u32);
 };
@@ -214,6 +223,20 @@ static const struct usb_endpoint_descriptor 
config_bulk_out_desc = {
.wMaxPacketSize = cpu_to_le16(EP0_MAX_PACKET),
 };
 
+/**
+ * xudc_write64 - write 64bit value to device registers
+ * @addr: base addr of device registers
+ * @offset: register offset
+ * @val: data to be written
+ **/
+static void xudc_write64(struct xusb_ep *ep, u32 offset, u64 val)
+{
+   struct xusb_udc *udc = ep->udc;
+
+   udc->write_fn(udc->addr, offset, lower_32_bits(val));
+   udc->write_fn(udc->addr, offset+0x04, upper_32_bits(val));
+}
+
 /**
  * xudc_write32 - little endian write to device registers
  * @addr: base addr of device registers
@@ -330,8 +353,13 @@ static int xudc_start_dma(struct xusb_ep *ep, dma_addr_t 
src,
 * destination registers and then set the length
 * into the DMA length register.
 */
-   udc->write_fn(udc->addr, XUSB_DMA_DSAR_ADDR_OFFSET, src);
-   udc->write_fn(udc->addr, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+   if (udc->dma_addrwidth > 32) {
+   xudc_write64(ep, XUSB_DMA_DSAR_ADDR_OFFSET_LSB, src);
+   xudc_write64(ep, XUSB_DMA_DDAR_ADDR_OFFSET_LSB, dst);
+   } else {
+   udc->write_fn(udc->addr, XUSB_DMA_DSAR_ADDR_OFFSET, src);
+   udc->write_fn(udc->addr, XUSB_DMA_DDAR_ADDR_OFFSET, dst);
+   }
udc->write_fn(udc->addr, XUSB_DMA_LENGTH_OFFSET, length);
 
/*
@@ -2097,6 +2125,24 @@ static int 

Re: [PATCH] Fix for hang of Ordered task in TCM

[Nicholas A. Bellinger]

On Wed, 2016-05-18 at 14:35 -0500, Michael Cyr wrote:
> On 5/18/16 12:53 AM, Nicholas A. Bellinger wrote:
> > Hi Michael,
> >
> > On Fri, 2016-05-13 at 17:15 -0500, Michael Cyr wrote:
> >> If a command with a Simple task attribute is failed due to a Unit
> >> Attention, then a subsequent command with an Ordered task attribute will
> >> hang forever.  The reason for this is that the Unit Attention status is
> >> checked for in target_setup_cmd_from_cdb, before the call to
> >> target_execute_cmd, which calls target_handle_task_attr, which in turn
> >> increments dev->simple_cmds.  However, transport_generic_request_failure
> >> still calls transport_complete_task_attr, which will decrement
> >> dev->simple_cmds.  In this case, simple_cmds is now -1.  So when a
> >> command with the Ordered task attribute is sent, target_handle_task_attr
> >> sees that dev->simple_cmds is not 0, so it decides it can't execute the
> >> command until all the (nonexistent) Simple commands have completed.
> >>
> > Thanks for reporting this bug.  Comments below.



> > So AFAICT for delayed commands, the above patch ends up skipping these
> > three checks subsequently when doing __target_execute_cmd() directly
> > from target_restart_delayed_cmds(), no..?
> >
> > After pondering this some more, what about moving these checks into
> > __target_execute_cmd() to handle both target_core_transport.c cases
> > instead..?
>>
> You're right, __target_execute_cmd is clearly the right place for the 
> checks.
>
> > We'll also need a parameter for internal COMPARE_AND_WRITE usage
> > within compare_and_write_callback(), to bypass checks upon secondary
> > ->execute_cmd() WRITE payload submission after READ + COMPARE has
> > completed successfully.
>>
> I'm still learning about the target code, and I was unaware of 
> COMPARE_AND_WRITE.  Thanks for pointing this out to me.  You're right 
> here too, we need to make sure we only make the tests when the Compare 
> and Write is first executed (to do the read), and not later when the 
> write is done.
> >
> > WDYT..?
>>
> You've covered all the places that call __target_execute_cmd, so I think 
> it's good.

Thanks for the feedback.

Given the nature of the change, it needs some more Reviewed-by +
Tested-By (across different drivers) ahead of pushing this patch into
mainline.

So for the moment it's in target-pending/queue as a post v4.7-rc1 item
here:

https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=queue=0c141c33b667b6538e38b87db87232523bcd4f5b

Re: [PATCH] Fix for hang of Ordered task in TCM

[Nicholas A. Bellinger]

On Wed, 2016-05-18 at 14:35 -0500, Michael Cyr wrote:
> On 5/18/16 12:53 AM, Nicholas A. Bellinger wrote:
> > Hi Michael,
> >
> > On Fri, 2016-05-13 at 17:15 -0500, Michael Cyr wrote:
> >> If a command with a Simple task attribute is failed due to a Unit
> >> Attention, then a subsequent command with an Ordered task attribute will
> >> hang forever.  The reason for this is that the Unit Attention status is
> >> checked for in target_setup_cmd_from_cdb, before the call to
> >> target_execute_cmd, which calls target_handle_task_attr, which in turn
> >> increments dev->simple_cmds.  However, transport_generic_request_failure
> >> still calls transport_complete_task_attr, which will decrement
> >> dev->simple_cmds.  In this case, simple_cmds is now -1.  So when a
> >> command with the Ordered task attribute is sent, target_handle_task_attr
> >> sees that dev->simple_cmds is not 0, so it decides it can't execute the
> >> command until all the (nonexistent) Simple commands have completed.
> >>
> > Thanks for reporting this bug.  Comments below.



> > So AFAICT for delayed commands, the above patch ends up skipping these
> > three checks subsequently when doing __target_execute_cmd() directly
> > from target_restart_delayed_cmds(), no..?
> >
> > After pondering this some more, what about moving these checks into
> > __target_execute_cmd() to handle both target_core_transport.c cases
> > instead..?
>>
> You're right, __target_execute_cmd is clearly the right place for the 
> checks.
>
> > We'll also need a parameter for internal COMPARE_AND_WRITE usage
> > within compare_and_write_callback(), to bypass checks upon secondary
> > ->execute_cmd() WRITE payload submission after READ + COMPARE has
> > completed successfully.
>>
> I'm still learning about the target code, and I was unaware of 
> COMPARE_AND_WRITE.  Thanks for pointing this out to me.  You're right 
> here too, we need to make sure we only make the tests when the Compare 
> and Write is first executed (to do the read), and not later when the 
> write is done.
> >
> > WDYT..?
>>
> You've covered all the places that call __target_execute_cmd, so I think 
> it's good.

Thanks for the feedback.

Given the nature of the change, it needs some more Reviewed-by +
Tested-By (across different drivers) ahead of pushing this patch into
mainline.

So for the moment it's in target-pending/queue as a post v4.7-rc1 item
here:

https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=queue=0c141c33b667b6538e38b87db87232523bcd4f5b

[PATCH] drm: rcar-du: EPROBE_DEFER case doesn't need error message

[Kuninori Morimoto]

From: Kuninori Morimoto 

EPROBE_DEFER is not error, thus, error message on kernel log on this
case is confusable for user. Prints it only error cases.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 26fd3ba..1db080c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -354,14 +354,16 @@ static int rcar_du_probe(struct platform_device *pdev)
 */
ret = drm_vblank_init(ddev, (1 << rcdu->info->num_crtcs) - 1);
if (ret < 0) {
-   dev_err(>dev, "failed to initialize vblank\n");
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "failed to initialize vblank\n");
goto error;
}
 
/* DRM/KMS objects */
ret = rcar_du_modeset_init(rcdu);
if (ret < 0) {
-   dev_err(>dev, "failed to initialize DRM/KMS (%d)\n", ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "failed to initialize DRM/KMS 
(%d)\n", ret);
goto error;
}
 
-- 
1.9.1

[PATCH] drm: rcar-du: EPROBE_DEFER case doesn't need error message

[Kuninori Morimoto]

From: Kuninori Morimoto 

EPROBE_DEFER is not error, thus, error message on kernel log on this
case is confusable for user. Prints it only error cases.

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 26fd3ba..1db080c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -354,14 +354,16 @@ static int rcar_du_probe(struct platform_device *pdev)
 */
ret = drm_vblank_init(ddev, (1 << rcdu->info->num_crtcs) - 1);
if (ret < 0) {
-   dev_err(>dev, "failed to initialize vblank\n");
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "failed to initialize vblank\n");
goto error;
}
 
/* DRM/KMS objects */
ret = rcar_du_modeset_init(rcdu);
if (ret < 0) {
-   dev_err(>dev, "failed to initialize DRM/KMS (%d)\n", ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "failed to initialize DRM/KMS 
(%d)\n", ret);
goto error;
}
 
-- 
1.9.1

Re: x86: A process doesn't stop on hw breakpoints sometimes

[Andrei Vagin]

On Mon, May 23, 2016 at 6:28 PM, Andrei Vagin  wrote:
> On Mon, May 23, 2016 at 4:05 PM, Andrei Vagin  wrote:
>> Hi,
>>
>> We use breakpoints on CRIU to stop a processes before calling
>> rt_sigreturn and we found that sometimes a process runs through a
>> break-point without stopping on it.
>>
>> https://github.com/xemul/criu/issues/162
>>
>>
>> A small reproducer is attached. It forks a child, stops it, sets a
>> breakpoint, executes a child, waits when it stops on the breakpoint. I
>> execute it a few times concurrently and wait a few minutes.
>>
>> https://asciinema.org/a/006l3u5v82ubbkfy9fto07agd
>
> I reproduced this issue on 4.4.9-300.fc23.x86_64

Oops. I can't reproduce this issue on 4.6 and 4.5. Looks like it was
fixed between 4.4 and 4.5. Sorry for the noise.

>
>>
>> I know that it can be reproduced on:
>> AMD A10 Micro-6700T
>> Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
>> Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
>>
>> so It doesn't look like a bug in a processor.
>>
>> Thanks,
>> Andrew

Re: x86: A process doesn't stop on hw breakpoints sometimes

[Andrei Vagin]

On Mon, May 23, 2016 at 6:28 PM, Andrei Vagin  wrote:
> On Mon, May 23, 2016 at 4:05 PM, Andrei Vagin  wrote:
>> Hi,
>>
>> We use breakpoints on CRIU to stop a processes before calling
>> rt_sigreturn and we found that sometimes a process runs through a
>> break-point without stopping on it.
>>
>> https://github.com/xemul/criu/issues/162
>>
>>
>> A small reproducer is attached. It forks a child, stops it, sets a
>> breakpoint, executes a child, waits when it stops on the breakpoint. I
>> execute it a few times concurrently and wait a few minutes.
>>
>> https://asciinema.org/a/006l3u5v82ubbkfy9fto07agd
>
> I reproduced this issue on 4.4.9-300.fc23.x86_64

Oops. I can't reproduce this issue on 4.6 and 4.5. Looks like it was
fixed between 4.4 and 4.5. Sorry for the noise.

>
>>
>> I know that it can be reproduced on:
>> AMD A10 Micro-6700T
>> Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
>> Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
>>
>> so It doesn't look like a bug in a processor.
>>
>> Thanks,
>> Andrew

Re: [PATCH v6 11/12] zsmalloc: page migration support

[Sergey Senozhatsky]

On (05/20/16 23:23), Minchan Kim wrote:
[..]
> +static int get_zspage_isolation(struct zspage *zspage)
> +{
> + return zspage->isolated;
> +}
> +

may be is_zspage_isolated()?

[..]
> @@ -502,23 +556,19 @@ static int get_size_class_index(int size)
>  static inline void zs_stat_inc(struct size_class *class,
>   enum zs_stat_type type, unsigned long cnt)
>  {
> - if (type < NR_ZS_STAT_TYPE)
> - class->stats.objs[type] += cnt;
> + class->stats.objs[type] += cnt;
>  }
>  
>  static inline void zs_stat_dec(struct size_class *class,
>   enum zs_stat_type type, unsigned long cnt)
>  {
> - if (type < NR_ZS_STAT_TYPE)
> - class->stats.objs[type] -= cnt;
> + class->stats.objs[type] -= cnt;
>  }
>  
>  static inline unsigned long zs_stat_get(struct size_class *class,
>   enum zs_stat_type type)
>  {
> - if (type < NR_ZS_STAT_TYPE)
> - return class->stats.objs[type];
> - return 0;
> + return class->stats.objs[type];
>  }

hmm... the ordering of STAT types and those if-conditions were here for
a reason:

commit 6fe5186f0c7c18a8beb6d96c21e2390df7a12375
Author: Sergey Senozhatsky 
Date:   Fri Nov 6 16:29:38 2015 -0800

zsmalloc: reduce size_class memory usage

Each `struct size_class' contains `struct zs_size_stat': an array of
NR_ZS_STAT_TYPE `unsigned long'.  For zsmalloc built with no
CONFIG_ZSMALLOC_STAT this results in a waste of `2 * sizeof(unsigned
long)' per-class.

The patch removes unneeded `struct zs_size_stat' members by redefining
NR_ZS_STAT_TYPE (max stat idx in array).

Since both NR_ZS_STAT_TYPE and zs_stat_type are compile time constants,
GCC can eliminate zs_stat_inc()/zs_stat_dec() calls that use zs_stat_type
larger than NR_ZS_STAT_TYPE: CLASS_ALMOST_EMPTY and CLASS_ALMOST_FULL at
the moment.

./scripts/bloat-o-meter mm/zsmalloc.o.old mm/zsmalloc.o.new
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-39 (-39)
function old new   delta
fix_fullness_group97  94  -3
insert_zspage100  86 -14
remove_zspage141 119 -22

To summarize:
a) each class now uses less memory
b) we avoid a number of dec/inc stats (a minor optimization,
   but still).

The gain will increase once we introduce additional stats.

so it helped to eliminate instructions at compile time from a very hot
path for !CONFIG_ZSMALLOC_STAT builds (which is 99% of the builds I think,
I doubt anyone apart from us is using ZSMALLOC_STAT).


[..]
> +static int get_first_obj_offset(struct size_class *class,
> + struct page *first_page, struct page *page)
>  {
> - return page->next;
> + int pos, bound;
> + int page_idx = 0;
> + int ofs = 0;
> + struct page *cursor = first_page;
> +
> + if (first_page == page)
> + goto out;
> +
> + while (page != cursor) {
> + page_idx++;
> + cursor = get_next_page(cursor);
> + }
> +
> + bound = PAGE_SIZE * page_idx;

'bound' not used.


> + pos = (((class->objs_per_zspage * class->size) *
> + page_idx / class->pages_per_zspage) / class->size
> +   ) * class->size;


something went wrong with the indentation here :)

so... it's

(((class->objs_per_zspage * class->size) * page_idx / 
class->pages_per_zspage) / class->size ) * class->size;

the last ' / class->size ) * class->size' can be dropped, I think.

[..]
> + pos += class->size;
> + }
> +
> + /*
> +  * Here, any user cannot access all objects in the zspage so let's move.
 "no one can access any object" ?

[..]
> + spin_lock(>lock);
> + dec_zspage_isolation(zspage);
> + if (!get_zspage_isolation(zspage)) {
> + fg = putback_zspage(class, zspage);
> + /*
> +  * Due to page_lock, we cannot free zspage immediately
> +  * so let's defer.
> +  */
> + if (fg == ZS_EMPTY)
> + schedule_work(>free_work);

hm... zsmalloc is getting sooo complex now.

`system_wq' -- can we have problems here when the system is getting
low on memory and workers are getting increasingly busy trying to
allocate the memory for some other purposes?

_theoretically_ zsmalloc can stack a number of ready-to-release zspages,
which won't be accessible to zsmalloc, nor will they be released. how likely
is this? hm, can zsmalloc take zspages from that deferred release list when
it wants to allocate a new zspage?

do you also want to kick the deferred page release from the shrinker
callback, for example?

-ss

Re: [PATCH v6 11/12] zsmalloc: page migration support

[Sergey Senozhatsky]

On (05/20/16 23:23), Minchan Kim wrote:
[..]
> +static int get_zspage_isolation(struct zspage *zspage)
> +{
> + return zspage->isolated;
> +}
> +

may be is_zspage_isolated()?

[..]
> @@ -502,23 +556,19 @@ static int get_size_class_index(int size)
>  static inline void zs_stat_inc(struct size_class *class,
>   enum zs_stat_type type, unsigned long cnt)
>  {
> - if (type < NR_ZS_STAT_TYPE)
> - class->stats.objs[type] += cnt;
> + class->stats.objs[type] += cnt;
>  }
>  
>  static inline void zs_stat_dec(struct size_class *class,
>   enum zs_stat_type type, unsigned long cnt)
>  {
> - if (type < NR_ZS_STAT_TYPE)
> - class->stats.objs[type] -= cnt;
> + class->stats.objs[type] -= cnt;
>  }
>  
>  static inline unsigned long zs_stat_get(struct size_class *class,
>   enum zs_stat_type type)
>  {
> - if (type < NR_ZS_STAT_TYPE)
> - return class->stats.objs[type];
> - return 0;
> + return class->stats.objs[type];
>  }

hmm... the ordering of STAT types and those if-conditions were here for
a reason:

commit 6fe5186f0c7c18a8beb6d96c21e2390df7a12375
Author: Sergey Senozhatsky 
Date:   Fri Nov 6 16:29:38 2015 -0800

zsmalloc: reduce size_class memory usage

Each `struct size_class' contains `struct zs_size_stat': an array of
NR_ZS_STAT_TYPE `unsigned long'.  For zsmalloc built with no
CONFIG_ZSMALLOC_STAT this results in a waste of `2 * sizeof(unsigned
long)' per-class.

The patch removes unneeded `struct zs_size_stat' members by redefining
NR_ZS_STAT_TYPE (max stat idx in array).

Since both NR_ZS_STAT_TYPE and zs_stat_type are compile time constants,
GCC can eliminate zs_stat_inc()/zs_stat_dec() calls that use zs_stat_type
larger than NR_ZS_STAT_TYPE: CLASS_ALMOST_EMPTY and CLASS_ALMOST_FULL at
the moment.

./scripts/bloat-o-meter mm/zsmalloc.o.old mm/zsmalloc.o.new
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-39 (-39)
function old new   delta
fix_fullness_group97  94  -3
insert_zspage100  86 -14
remove_zspage141 119 -22

To summarize:
a) each class now uses less memory
b) we avoid a number of dec/inc stats (a minor optimization,
   but still).

The gain will increase once we introduce additional stats.

so it helped to eliminate instructions at compile time from a very hot
path for !CONFIG_ZSMALLOC_STAT builds (which is 99% of the builds I think,
I doubt anyone apart from us is using ZSMALLOC_STAT).


[..]
> +static int get_first_obj_offset(struct size_class *class,
> + struct page *first_page, struct page *page)
>  {
> - return page->next;
> + int pos, bound;
> + int page_idx = 0;
> + int ofs = 0;
> + struct page *cursor = first_page;
> +
> + if (first_page == page)
> + goto out;
> +
> + while (page != cursor) {
> + page_idx++;
> + cursor = get_next_page(cursor);
> + }
> +
> + bound = PAGE_SIZE * page_idx;

'bound' not used.


> + pos = (((class->objs_per_zspage * class->size) *
> + page_idx / class->pages_per_zspage) / class->size
> +   ) * class->size;


something went wrong with the indentation here :)

so... it's

(((class->objs_per_zspage * class->size) * page_idx / 
class->pages_per_zspage) / class->size ) * class->size;

the last ' / class->size ) * class->size' can be dropped, I think.

[..]
> + pos += class->size;
> + }
> +
> + /*
> +  * Here, any user cannot access all objects in the zspage so let's move.
 "no one can access any object" ?

[..]
> + spin_lock(>lock);
> + dec_zspage_isolation(zspage);
> + if (!get_zspage_isolation(zspage)) {
> + fg = putback_zspage(class, zspage);
> + /*
> +  * Due to page_lock, we cannot free zspage immediately
> +  * so let's defer.
> +  */
> + if (fg == ZS_EMPTY)
> + schedule_work(>free_work);

hm... zsmalloc is getting sooo complex now.

`system_wq' -- can we have problems here when the system is getting
low on memory and workers are getting increasingly busy trying to
allocate the memory for some other purposes?

_theoretically_ zsmalloc can stack a number of ready-to-release zspages,
which won't be accessible to zsmalloc, nor will they be released. how likely
is this? hm, can zsmalloc take zspages from that deferred release list when
it wants to allocate a new zspage?

do you also want to kick the deferred page release from the shrinker
callback, for example?

-ss

[PATCH] pinctrl: do not care about blank pin name

[Masahiro Yamada]

If a pin name is not specified in struct pinctrl_pin_desc,
pinctrl_register_one_pin() dynamically assigns its name.
So, desc->name is always a valid pointer here.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/core.c|  3 +--
 drivers/pinctrl/pinconf.c |  6 ++
 drivers/pinctrl/pinmux.c  | 14 --
 3 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 98d2a1b..03c08c1 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1367,8 +1367,7 @@ static int pinctrl_pins_show(struct seq_file *s, void 
*what)
if (desc == NULL)
continue;
 
-   seq_printf(s, "pin %d (%s) ", pin,
-  desc->name ? desc->name : "unnamed");
+   seq_printf(s, "pin %d (%s) ", pin, desc->name);
 
/* Driver-specific info per pin */
if (ops->pin_dbg_show)
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 4dd7722..3f1b6f0 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -258,8 +258,7 @@ void pinconf_show_setting(struct seq_file *s,
case PIN_MAP_TYPE_CONFIGS_PIN:
desc = pin_desc_get(setting->pctldev,
setting->data.configs.group_or_pin);
-   seq_printf(s, "pin %s (%d)",
-  desc->name ? desc->name : "unnamed",
+   seq_printf(s, "pin %s (%d)", desc->name,
   setting->data.configs.group_or_pin);
break;
case PIN_MAP_TYPE_CONFIGS_GROUP:
@@ -311,8 +310,7 @@ static int pinconf_pins_show(struct seq_file *s, void *what)
if (desc == NULL)
continue;
 
-   seq_printf(s, "pin %d (%s):", pin,
-  desc->name ? desc->name : "unnamed");
+   seq_printf(s, "pin %d (%s):", pin, desc->name);
 
pinconf_dump_pin(pctldev, s, pin);
 
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index c223a9e..d94d76c 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -606,23 +606,17 @@ static int pinmux_pins_show(struct seq_file *s, void 
*what)
if (pmxops->strict) {
if (desc->mux_owner)
seq_printf(s, "pin %d (%s): device %s%s",
-  pin,
-  desc->name ? desc->name : "unnamed",
-  desc->mux_owner,
+  pin, desc->name, desc->mux_owner,
   is_hog ? " (HOG)" : "");
else if (desc->gpio_owner)
seq_printf(s, "pin %d (%s): GPIO %s",
-  pin,
-  desc->name ? desc->name : "unnamed",
-  desc->gpio_owner);
+  pin, desc->name, desc->gpio_owner);
else
seq_printf(s, "pin %d (%s): UNCLAIMED",
-  pin,
-  desc->name ? desc->name : "unnamed");
+  pin, desc->name);
} else {
/* For non-strict controllers */
-   seq_printf(s, "pin %d (%s): %s %s%s", pin,
-  desc->name ? desc->name : "unnamed",
+   seq_printf(s, "pin %d (%s): %s %s%s", pin, desc->name,
   desc->mux_owner ? desc->mux_owner
   : "(MUX UNCLAIMED)",
   desc->gpio_owner ? desc->gpio_owner
-- 
1.9.1

[PATCH] pinctrl: do not care about blank pin name

[Masahiro Yamada]

If a pin name is not specified in struct pinctrl_pin_desc,
pinctrl_register_one_pin() dynamically assigns its name.
So, desc->name is always a valid pointer here.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/core.c|  3 +--
 drivers/pinctrl/pinconf.c |  6 ++
 drivers/pinctrl/pinmux.c  | 14 --
 3 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 98d2a1b..03c08c1 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1367,8 +1367,7 @@ static int pinctrl_pins_show(struct seq_file *s, void 
*what)
if (desc == NULL)
continue;
 
-   seq_printf(s, "pin %d (%s) ", pin,
-  desc->name ? desc->name : "unnamed");
+   seq_printf(s, "pin %d (%s) ", pin, desc->name);
 
/* Driver-specific info per pin */
if (ops->pin_dbg_show)
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 4dd7722..3f1b6f0 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -258,8 +258,7 @@ void pinconf_show_setting(struct seq_file *s,
case PIN_MAP_TYPE_CONFIGS_PIN:
desc = pin_desc_get(setting->pctldev,
setting->data.configs.group_or_pin);
-   seq_printf(s, "pin %s (%d)",
-  desc->name ? desc->name : "unnamed",
+   seq_printf(s, "pin %s (%d)", desc->name,
   setting->data.configs.group_or_pin);
break;
case PIN_MAP_TYPE_CONFIGS_GROUP:
@@ -311,8 +310,7 @@ static int pinconf_pins_show(struct seq_file *s, void *what)
if (desc == NULL)
continue;
 
-   seq_printf(s, "pin %d (%s):", pin,
-  desc->name ? desc->name : "unnamed");
+   seq_printf(s, "pin %d (%s):", pin, desc->name);
 
pinconf_dump_pin(pctldev, s, pin);
 
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index c223a9e..d94d76c 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -606,23 +606,17 @@ static int pinmux_pins_show(struct seq_file *s, void 
*what)
if (pmxops->strict) {
if (desc->mux_owner)
seq_printf(s, "pin %d (%s): device %s%s",
-  pin,
-  desc->name ? desc->name : "unnamed",
-  desc->mux_owner,
+  pin, desc->name, desc->mux_owner,
   is_hog ? " (HOG)" : "");
else if (desc->gpio_owner)
seq_printf(s, "pin %d (%s): GPIO %s",
-  pin,
-  desc->name ? desc->name : "unnamed",
-  desc->gpio_owner);
+  pin, desc->name, desc->gpio_owner);
else
seq_printf(s, "pin %d (%s): UNCLAIMED",
-  pin,
-  desc->name ? desc->name : "unnamed");
+  pin, desc->name);
} else {
/* For non-strict controllers */
-   seq_printf(s, "pin %d (%s): %s %s%s", pin,
-  desc->name ? desc->name : "unnamed",
+   seq_printf(s, "pin %d (%s): %s %s%s", pin, desc->name,
   desc->mux_owner ? desc->mux_owner
   : "(MUX UNCLAIMED)",
   desc->gpio_owner ? desc->gpio_owner
-- 
1.9.1

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

On Fri, May 20, 2016 at 09:24:35AM -0700, Thomas Garnier wrote:
> On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim  wrote:
> > 2016-05-20 5:20 GMT+09:00 Thomas Garnier :
> >> I ran the test given by Joonsoo and it gave me these minimum cycles
> >> per size across 20 usage:
> >
> > I can't understand what you did here. Maybe, it's due to my poor Engling.
> > Please explain more. You did single thread test? Why minimum cycles
> > rather than average?
> >
> 
> I used your version of slab_test and ran it 20 times for each
> versions. I compared
> the minimum number of cycles as an optimal case for comparison. As you said
> slab_test results can be unreliable. Comparing the average across multiple 
> runs
> always gave odd results.

Hmm... With my version, slab_test results seems to be reliable for me. You
can use average result in this case. Anyway, your minimum result looks
odd even if my version is used. Large sized test would go slowpath
more frequently so it should be worse.

> 
> >> size,before,after
> >> 8,63.00,64.50 (102.38%)
> >> 16,64.50,65.00 (100.78%)
> >> 32,65.00,65.00 (100.00%)
> >> 64,66.00,65.00 (98.48%)
> >> 128,66.00,65.00 (98.48%)
> >> 256,64.00,64.00 (100.00%)
> >> 512,65.00,66.00 (101.54%)
> >> 1024,68.00,64.00 (94.12%)
> >> 2048,66.00,65.00 (98.48%)
> >> 4096,66.00,66.00 (100.00%)
> >
> > It looks like performance of all size classes are the same?
> >
> >> I assume the difference is bigger if you don't have RDRAND support.
> >
> > What does RDRAND means? Kconfig? How can I check if I have RDRAND?
> >
> 
> Sorry, I was referring to the usage of get_random_bytes_arch which
> will be faster
> if the test machine support specific instructions (like RDRAND).

Thanks! I checked that my test bed (QEMU) doesn't support rdrand.
(/proc/cpuinfo)

> >> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
> >> to disable additional randomization per new page? It will remove
> >> additional entropy but increase performance for machines without arch
> >> specific randomization instructions.
> >
> > I don't think that it deserve another CONFIG. If performance is a matter,
> > I think that removing additional entropy is better until it is proved that
> > entropy is a problem.
> >
> 
> I will do more testing before the next RFC to decide the best approach.

Okay.

Thanks.

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

[Joonsoo Kim]

On Fri, May 20, 2016 at 09:24:35AM -0700, Thomas Garnier wrote:
> On Thu, May 19, 2016 at 7:15 PM, Joonsoo Kim  wrote:
> > 2016-05-20 5:20 GMT+09:00 Thomas Garnier :
> >> I ran the test given by Joonsoo and it gave me these minimum cycles
> >> per size across 20 usage:
> >
> > I can't understand what you did here. Maybe, it's due to my poor Engling.
> > Please explain more. You did single thread test? Why minimum cycles
> > rather than average?
> >
> 
> I used your version of slab_test and ran it 20 times for each
> versions. I compared
> the minimum number of cycles as an optimal case for comparison. As you said
> slab_test results can be unreliable. Comparing the average across multiple 
> runs
> always gave odd results.

Hmm... With my version, slab_test results seems to be reliable for me. You
can use average result in this case. Anyway, your minimum result looks
odd even if my version is used. Large sized test would go slowpath
more frequently so it should be worse.

> 
> >> size,before,after
> >> 8,63.00,64.50 (102.38%)
> >> 16,64.50,65.00 (100.78%)
> >> 32,65.00,65.00 (100.00%)
> >> 64,66.00,65.00 (98.48%)
> >> 128,66.00,65.00 (98.48%)
> >> 256,64.00,64.00 (100.00%)
> >> 512,65.00,66.00 (101.54%)
> >> 1024,68.00,64.00 (94.12%)
> >> 2048,66.00,65.00 (98.48%)
> >> 4096,66.00,66.00 (100.00%)
> >
> > It looks like performance of all size classes are the same?
> >
> >> I assume the difference is bigger if you don't have RDRAND support.
> >
> > What does RDRAND means? Kconfig? How can I check if I have RDRAND?
> >
> 
> Sorry, I was referring to the usage of get_random_bytes_arch which
> will be faster
> if the test machine support specific instructions (like RDRAND).

Thanks! I checked that my test bed (QEMU) doesn't support rdrand.
(/proc/cpuinfo)

> >> Christoph, Joonsoo: Do you think it would be valuable to add a CONFIG
> >> to disable additional randomization per new page? It will remove
> >> additional entropy but increase performance for machines without arch
> >> specific randomization instructions.
> >
> > I don't think that it deserve another CONFIG. If performance is a matter,
> > I think that removing additional entropy is better until it is proved that
> > entropy is a problem.
> >
> 
> I will do more testing before the next RFC to decide the best approach.

Okay.

Thanks.

Re: [RFC PATCH 1/2] Input: rotary-encoder- Add support for absolute encoder

[Vignesh R]

Hi,

On 05/23/2016 06:48 PM, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, May 23, 2016 at 04:48:40PM +0530, R, Vignesh wrote:
>> On 5/22/2016 3:56 PM, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Thu, May 19, 2016 at 02:34:00PM +0530, Vignesh R wrote:
 There are rotary-encoders where GPIO lines reflect the actual position
 of the rotary encoder dial. For example, if dial points to 9, then four
 GPIO lines connected to the rotary encoder will read HLLH(1001b = 9).
 Add support for such rotary-encoder.
 The driver relies on rotary-encoder,absolute-encoder DT property to
 detect such encoders.
 Since, GPIO IRQs are not necessary to work with
 such encoders, optional polling mode support is added using
>>>
>>> I don't understand this. It's necessary in the same way as with the
>>> already supported devices. I.e. you want to trigger an irq when the
>>> encoder is moved and then check for it's position in the handler.
>>>
>>
>> Unlike already supported device, there is no need to count steps or
>> determine the direction of rotation. Hence, IRQ is not a requirement,
>> periodically polling the gpio lines is more than sufficient. With
>> absolute encoder, you are able to determine the current position at any
>> time just by looking at the gpio inputs.
> 
> The timing might not be that critical, but there is no reason to operate
> this device without irqs, is there?

No, I am not against the use of IRQs. In fact, my patches add support
for both IRQ based(default) and polling based operation(optional). If
rotary-encoder does not have interrupt capable gpio lines connected to
it (like am335x-ice) then one can make use of the polling mode support.

> 
>> Suppose we poll device at t=0ms and see gpio values are LLLH(1), if we
>> again poll device at t=500ms(which is what input_poll_dev helps to do)
>> and see that gpio values is LLHH(3), then we know that rotary encoder
>> has changed to 3. This can be done w/o IRQ for absolute encoders.
>>
 diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt 
 b/Documentation/devicetree/bindings/input/rotary-encoder.txt
 index 6c9f0c8a846c..9c928dbd1500 100644
 --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
 +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
 @@ -12,6 +12,10 @@ Optional properties:
  - rotary-encoder,relative-axis: register a relative axis rather than an
absolute one. Relative axis will only generate +1/-1 events on the input
device, hence no steps need to be passed.
 +- rotary-encoder,absolute-encoder: support encoders where GPIO lines
 +  reflect the actual position of the rotary encoder dial. For example,
 +  if dial points to 9, then four GPIO lines read HLLH(1001b = 9).
 +  In this case, rotary-encoder,steps-per-period needed not be defined.
>>>
>>> IMHO this is wrong, I'd formalize this device as:
>>>
>>> {
>>> compatible = "rotary-encoder";
>>> gpios = < 19 1>, < 20 0>, <...>, <...>;
>>> rotary-encoder,encoding = "binary";
>>> rotary-encoder,steps = <16>;
>>> rotary-encoder,steps-per-period = <16>;
>>
>> The above bindings essential means quarter_period device. I would not
>> like to bother with all the logic in rotary_encoder_quarter_period_irq()
>> when we can know encoder->pos by directly reading state of gpio lines.
> 
> OK, we have code that is more complex than it needs to be for your
> device. But your device is a special case of the supported devices, so
> I'd say don't bother that there is more logic in the driver than you
> need and be lucky.
> 

More complexity is just a overhead. Since, encoder can be turned at a
rate faster than handling of IRQs (rotary_encoder_quarter_period_irq()
is threaded IRQ hence, priority is not close to real time), some states
can be missed. rotary_encoder_quarter_period_irq() is not robust in this
case, reading gpios directly is more suitable option. I see similar
views expressed in previously[1]

[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/391196.html

-- 
Regards
Vignesh

Re: [RFC PATCH 1/2] Input: rotary-encoder- Add support for absolute encoder

[Vignesh R]

Hi,

On 05/23/2016 06:48 PM, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, May 23, 2016 at 04:48:40PM +0530, R, Vignesh wrote:
>> On 5/22/2016 3:56 PM, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Thu, May 19, 2016 at 02:34:00PM +0530, Vignesh R wrote:
 There are rotary-encoders where GPIO lines reflect the actual position
 of the rotary encoder dial. For example, if dial points to 9, then four
 GPIO lines connected to the rotary encoder will read HLLH(1001b = 9).
 Add support for such rotary-encoder.
 The driver relies on rotary-encoder,absolute-encoder DT property to
 detect such encoders.
 Since, GPIO IRQs are not necessary to work with
 such encoders, optional polling mode support is added using
>>>
>>> I don't understand this. It's necessary in the same way as with the
>>> already supported devices. I.e. you want to trigger an irq when the
>>> encoder is moved and then check for it's position in the handler.
>>>
>>
>> Unlike already supported device, there is no need to count steps or
>> determine the direction of rotation. Hence, IRQ is not a requirement,
>> periodically polling the gpio lines is more than sufficient. With
>> absolute encoder, you are able to determine the current position at any
>> time just by looking at the gpio inputs.
> 
> The timing might not be that critical, but there is no reason to operate
> this device without irqs, is there?

No, I am not against the use of IRQs. In fact, my patches add support
for both IRQ based(default) and polling based operation(optional). If
rotary-encoder does not have interrupt capable gpio lines connected to
it (like am335x-ice) then one can make use of the polling mode support.

> 
>> Suppose we poll device at t=0ms and see gpio values are LLLH(1), if we
>> again poll device at t=500ms(which is what input_poll_dev helps to do)
>> and see that gpio values is LLHH(3), then we know that rotary encoder
>> has changed to 3. This can be done w/o IRQ for absolute encoders.
>>
 diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt 
 b/Documentation/devicetree/bindings/input/rotary-encoder.txt
 index 6c9f0c8a846c..9c928dbd1500 100644
 --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
 +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
 @@ -12,6 +12,10 @@ Optional properties:
  - rotary-encoder,relative-axis: register a relative axis rather than an
absolute one. Relative axis will only generate +1/-1 events on the input
device, hence no steps need to be passed.
 +- rotary-encoder,absolute-encoder: support encoders where GPIO lines
 +  reflect the actual position of the rotary encoder dial. For example,
 +  if dial points to 9, then four GPIO lines read HLLH(1001b = 9).
 +  In this case, rotary-encoder,steps-per-period needed not be defined.
>>>
>>> IMHO this is wrong, I'd formalize this device as:
>>>
>>> {
>>> compatible = "rotary-encoder";
>>> gpios = < 19 1>, < 20 0>, <...>, <...>;
>>> rotary-encoder,encoding = "binary";
>>> rotary-encoder,steps = <16>;
>>> rotary-encoder,steps-per-period = <16>;
>>
>> The above bindings essential means quarter_period device. I would not
>> like to bother with all the logic in rotary_encoder_quarter_period_irq()
>> when we can know encoder->pos by directly reading state of gpio lines.
> 
> OK, we have code that is more complex than it needs to be for your
> device. But your device is a special case of the supported devices, so
> I'd say don't bother that there is more logic in the driver than you
> need and be lucky.
> 

More complexity is just a overhead. Since, encoder can be turned at a
rate faster than handling of IRQs (rotary_encoder_quarter_period_irq()
is threaded IRQ hence, priority is not close to real time), some states
can be missed. rotary_encoder_quarter_period_irq() is not robust in this
case, reading gpios directly is more suitable option. I see similar
views expressed in previously[1]

[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/391196.html

-- 
Regards
Vignesh

[PATCH v2 10/10] drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

[Yakir Yang]

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
 };
 
 enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
 };
 
 struct video_info {
-- 
1.9.1

[PATCH v2 08/10] drm/rockchip: analogix_dp: correct the connector display color format and bpc

[Yakir Yang]

Rockchip VOP couldn't output YUV video format for eDP controller, so
when driver detect connector support YUV video format, we need to hack
it down to RGB888.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index f29ca3d..910cceb 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -97,6 +97,24 @@ static int rockchip_dp_powerdown(struct 
analogix_dp_plat_data *plat_data)
return 0;
 }
 
+static enum drm_mode_status
+rockchip_dp_mode_valid(struct analogix_dp_plat_data *plat_data,
+  struct drm_connector *connector,
+  struct drm_display_mode *mode)
+{
+   struct drm_display_info *di = >display_info;
+
+   if (di->color_formats & DRM_COLOR_FORMAT_YCRCB444 ||
+   di->color_formats & DRM_COLOR_FORMAT_YCRCB422) {
+   di->color_formats &= ~(DRM_COLOR_FORMAT_YCRCB422 |
+  DRM_COLOR_FORMAT_YCRCB444);
+   di->color_formats |= DRM_COLOR_FORMAT_RGB444;
+   di->bpc = 8;
+   }
+
+   return MODE_OK;
+}
+
 static bool
 rockchip_dp_drm_encoder_mode_fixup(struct drm_encoder *encoder,
   const struct drm_display_mode *mode,
@@ -306,6 +324,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.subdev_type = dp_data->chip_type;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
+   dp->plat_data.mode_valid = rockchip_dp_mode_valid;
 
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
 }
-- 
1.9.1

[PATCH v2 06/10] drm/rockchip: analogix_dp: make panel detect to an optional action

[Yakir Yang]

Some boards don't need to declare a panel device node, like the
display interface is DP monitors, so it's necessary to make the
panel detect to an optional action.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 -
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d684c97..f29ca3d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -325,38 +325,34 @@ static int rockchip_dp_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct device_node *panel_node, *port, *endpoint;
+   struct drm_panel *panel = NULL;
struct rockchip_dp_device *dp;
-   struct drm_panel *panel;
 
port = of_graph_get_port_by_id(dev->of_node, 1);
-   if (!port) {
-   dev_err(dev, "can't find output port\n");
-   return -EINVAL;
-   }
-
-   endpoint = of_get_child_by_name(port, "endpoint");
-   of_node_put(port);
-   if (!endpoint) {
-   dev_err(dev, "no output endpoint found\n");
-   return -EINVAL;
-   }
-
-   panel_node = of_graph_get_remote_port_parent(endpoint);
-   of_node_put(endpoint);
-   if (!panel_node) {
-   dev_err(dev, "no output node found\n");
-   return -EINVAL;
-   }
-
-   panel = of_drm_find_panel(panel_node);
-   if (!panel) {
-   DRM_ERROR("failed to find panel\n");
+   if (port) {
+   endpoint = of_get_child_by_name(port, "endpoint");
+   of_node_put(port);
+   if (!endpoint) {
+   dev_err(dev, "no output endpoint found\n");
+   return -EINVAL;
+   }
+
+   panel_node = of_graph_get_remote_port_parent(endpoint);
+   of_node_put(endpoint);
+   if (!panel_node) {
+   dev_err(dev, "no output node found\n");
+   return -EINVAL;
+   }
+
+   panel = of_drm_find_panel(panel_node);
+   if (!panel) {
+   DRM_ERROR("failed to find panel\n");
+   of_node_put(panel_node);
+   return -EPROBE_DEFER;
+   }
of_node_put(panel_node);
-   return -EPROBE_DEFER;
}
 
-   of_node_put(panel_node);
-
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
if (!dp)
return -ENOMEM;
-- 
1.9.1

[PATCH v2 07/10] drm/bridge: analogix_dp: introduce connector mode_valid callback to plat driver

[Yakir Yang]

It's helpful to expand the mode_valid callback to platform driver,
so they could valid the display mode or information.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 +++
 include/drm/bridge/analogix_dp.h   |  4 
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a1b3b8..5af9ce4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -943,6 +943,20 @@ int analogix_dp_get_modes(struct drm_connector *connector)
return num_modes;
 }
 
+static enum drm_mode_status
+analogix_dp_mode_valid(struct drm_connector *connector,
+  struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+   enum drm_mode_status status = MODE_OK;
+
+   if (dp->plat_data->mode_valid)
+   status = dp->plat_data->mode_valid(dp->plat_data, connector,
+  mode);
+
+   return status;
+}
+
 static struct drm_encoder *
 analogix_dp_best_encoder(struct drm_connector *connector)
 {
@@ -954,6 +968,7 @@ analogix_dp_best_encoder(struct drm_connector *connector)
 static const struct drm_connector_helper_funcs 
analogix_dp_connector_helper_funcs = {
.get_modes = analogix_dp_get_modes,
.best_encoder = analogix_dp_best_encoder,
+   .mode_valid = analogix_dp_mode_valid,
 };
 
 enum drm_connector_status
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 82b8135..9ef89de 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -35,6 +35,10 @@ struct analogix_dp_plat_data {
int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
  struct drm_connector *);
int (*get_modes)(struct analogix_dp_plat_data *);
+
+   enum drm_mode_status (*mode_valid)(struct analogix_dp_plat_data *,
+  struct drm_connector *,
+  struct drm_display_mode *);
 };
 
 int analogix_dp_resume(struct device *dev);
-- 
1.9.1

[PATCH v2 10/10] drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

[Yakir Yang]

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
 };
 
 enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
 };
 
 struct video_info {
-- 
1.9.1

[PATCH v2 08/10] drm/rockchip: analogix_dp: correct the connector display color format and bpc

[Yakir Yang]

Rockchip VOP couldn't output YUV video format for eDP controller, so
when driver detect connector support YUV video format, we need to hack
it down to RGB888.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index f29ca3d..910cceb 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -97,6 +97,24 @@ static int rockchip_dp_powerdown(struct 
analogix_dp_plat_data *plat_data)
return 0;
 }
 
+static enum drm_mode_status
+rockchip_dp_mode_valid(struct analogix_dp_plat_data *plat_data,
+  struct drm_connector *connector,
+  struct drm_display_mode *mode)
+{
+   struct drm_display_info *di = >display_info;
+
+   if (di->color_formats & DRM_COLOR_FORMAT_YCRCB444 ||
+   di->color_formats & DRM_COLOR_FORMAT_YCRCB422) {
+   di->color_formats &= ~(DRM_COLOR_FORMAT_YCRCB422 |
+  DRM_COLOR_FORMAT_YCRCB444);
+   di->color_formats |= DRM_COLOR_FORMAT_RGB444;
+   di->bpc = 8;
+   }
+
+   return MODE_OK;
+}
+
 static bool
 rockchip_dp_drm_encoder_mode_fixup(struct drm_encoder *encoder,
   const struct drm_display_mode *mode,
@@ -306,6 +324,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.subdev_type = dp_data->chip_type;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
+   dp->plat_data.mode_valid = rockchip_dp_mode_valid;
 
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
 }
-- 
1.9.1

[PATCH v2 06/10] drm/rockchip: analogix_dp: make panel detect to an optional action

[Yakir Yang]

Some boards don't need to declare a panel device node, like the
display interface is DP monitors, so it's necessary to make the
panel detect to an optional action.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 -
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d684c97..f29ca3d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -325,38 +325,34 @@ static int rockchip_dp_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct device_node *panel_node, *port, *endpoint;
+   struct drm_panel *panel = NULL;
struct rockchip_dp_device *dp;
-   struct drm_panel *panel;
 
port = of_graph_get_port_by_id(dev->of_node, 1);
-   if (!port) {
-   dev_err(dev, "can't find output port\n");
-   return -EINVAL;
-   }
-
-   endpoint = of_get_child_by_name(port, "endpoint");
-   of_node_put(port);
-   if (!endpoint) {
-   dev_err(dev, "no output endpoint found\n");
-   return -EINVAL;
-   }
-
-   panel_node = of_graph_get_remote_port_parent(endpoint);
-   of_node_put(endpoint);
-   if (!panel_node) {
-   dev_err(dev, "no output node found\n");
-   return -EINVAL;
-   }
-
-   panel = of_drm_find_panel(panel_node);
-   if (!panel) {
-   DRM_ERROR("failed to find panel\n");
+   if (port) {
+   endpoint = of_get_child_by_name(port, "endpoint");
+   of_node_put(port);
+   if (!endpoint) {
+   dev_err(dev, "no output endpoint found\n");
+   return -EINVAL;
+   }
+
+   panel_node = of_graph_get_remote_port_parent(endpoint);
+   of_node_put(endpoint);
+   if (!panel_node) {
+   dev_err(dev, "no output node found\n");
+   return -EINVAL;
+   }
+
+   panel = of_drm_find_panel(panel_node);
+   if (!panel) {
+   DRM_ERROR("failed to find panel\n");
+   of_node_put(panel_node);
+   return -EPROBE_DEFER;
+   }
of_node_put(panel_node);
-   return -EPROBE_DEFER;
}
 
-   of_node_put(panel_node);
-
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
if (!dp)
return -ENOMEM;
-- 
1.9.1

[PATCH v2 07/10] drm/bridge: analogix_dp: introduce connector mode_valid callback to plat driver

[Yakir Yang]

It's helpful to expand the mode_valid callback to platform driver,
so they could valid the display mode or information.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 +++
 include/drm/bridge/analogix_dp.h   |  4 
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a1b3b8..5af9ce4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -943,6 +943,20 @@ int analogix_dp_get_modes(struct drm_connector *connector)
return num_modes;
 }
 
+static enum drm_mode_status
+analogix_dp_mode_valid(struct drm_connector *connector,
+  struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+   enum drm_mode_status status = MODE_OK;
+
+   if (dp->plat_data->mode_valid)
+   status = dp->plat_data->mode_valid(dp->plat_data, connector,
+  mode);
+
+   return status;
+}
+
 static struct drm_encoder *
 analogix_dp_best_encoder(struct drm_connector *connector)
 {
@@ -954,6 +968,7 @@ analogix_dp_best_encoder(struct drm_connector *connector)
 static const struct drm_connector_helper_funcs 
analogix_dp_connector_helper_funcs = {
.get_modes = analogix_dp_get_modes,
.best_encoder = analogix_dp_best_encoder,
+   .mode_valid = analogix_dp_mode_valid,
 };
 
 enum drm_connector_status
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 82b8135..9ef89de 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -35,6 +35,10 @@ struct analogix_dp_plat_data {
int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
  struct drm_connector *);
int (*get_modes)(struct analogix_dp_plat_data *);
+
+   enum drm_mode_status (*mode_valid)(struct analogix_dp_plat_data *,
+  struct drm_connector *,
+  struct drm_display_mode *);
 };
 
 int analogix_dp_resume(struct device *dev);
-- 
1.9.1

[PATCH v2 01/10] drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP

[Yakir Yang]

Rename RK3288_DP marcos to ROCKCHIP_DP, prepare to add eDP
support for more Rockchip chips.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 6 +++---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 2 +-
 include/drm/bridge/analogix_dp.h   | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7699597..4a1b3b8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1207,9 +1207,9 @@ static int analogix_dp_dt_parse_pdata(struct 
analogix_dp_device *dp)
struct video_info *video_info = >video_info;
 
switch (dp->plat_data->dev_type) {
-   case RK3288_DP:
+   case ROCKCHIP_DP:
/*
-* Like Rk3288 DisplayPort TRM indicate that "Main link
+* Like Rockchip DisplayPort TRM indicate that "Main link
 * containing 4 physical lanes of 2.7/1.62 Gbps/lane".
 */
video_info->max_link_rate = 0x0A;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 49205ef..931a76c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -74,7 +74,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
-   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP)) {
writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
@@ -244,7 +244,7 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
 
-   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP))
phy_pd_addr = ANALOGIX_DP_PD;
 
switch (block) {
@@ -448,7 +448,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
 
/* Disable AUX transaction H/W retry */
-   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP))
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
  AUX_HW_RETRY_COUNT_SEL(3) |
  AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 7f6a55c..2bc8a7e 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -270,7 +270,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
 
dp->plat_data.encoder = >encoder;
 
-   dp->plat_data.dev_type = RK3288_DP;
+   dp->plat_data.dev_type = ROCKCHIP_DP;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
 
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 25afb31..9e5d013 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -15,7 +15,7 @@
 
 enum analogix_dp_devtype {
EXYNOS_DP,
-   RK3288_DP,
+   ROCKCHIP_DP,
 };
 
 struct analogix_dp_plat_data {
-- 
1.9.1

[PATCH v2 03/10] drm/bridge: analogix_dp: correct the register bit define error in ANALOGIX_DP_PLL_REG_1

[Yakir Yang]

There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced
by commit bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special
registers setting").

The PHY PLL input clock source is selected by ANALOGIX_DP_PLL_REG_1
BIT 0, not BIT 1.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 337912b..88d56ad 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -163,8 +163,8 @@
 #define HSYNC_POLARITY_CFG (0x1 << 0)
 
 /* ANALOGIX_DP_PLL_REG_1 */
-#define REF_CLK_24M(0x1 << 1)
-#define REF_CLK_27M(0x0 << 1)
+#define REF_CLK_24M(0x1 << 0)
+#define REF_CLK_27M(0x0 << 0)
 
 /* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0 (0x0 << 6)
-- 
1.9.1

[PATCH v2 05/10] drm/rockchip: analogix_dp: add rk3399 eDP support

[Yakir Yang]

RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- rebase with drm-next, fix some conflicts

 .../bindings/display/bridge/analogix_dp.txt|  1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 34 --
 include/drm/bridge/analogix_dp.h   |  1 +
 4 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 4f2ba8c..4a0f4f7 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -5,6 +5,7 @@ Required properties for dp-controller:
platform specific such as:
 * "samsung,exynos5-dp"
 * "rockchip,rk3288-dp"
+* "rockchip,rk3399-edp"
-reg:
physical base address of the controller and length
of memory mapped region.
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index e832ff9..5ae55ca 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip RK3288 specific extensions to the Analogix Display Port
 
 
 Required properties:
-- compatible: "rockchip,rk3288-edp";
+- compatible: "rockchip,rk3288-edp" or "rockchip,rk3399-edp";
 
 - reg: physical base address of the controller and length
 
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 29c4105..d684c97 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -149,6 +149,8 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
 {
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
 
+   s->output_type = DRM_MODE_CONNECTOR_eDP;
+
/*
 * FIXME(Yakir): driver should configure the CRTC output video
 * mode with the display information which indicated the monitor
@@ -162,8 +164,27 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
 * But if I configure CTRC to RGBaaa, and eDP driver still keep
 * RGB666 input video mode, then screen would works prefect.
 */
-   s->output_mode = ROCKCHIP_OUT_MODE_;
-   s->output_type = DRM_MODE_CONNECTOR_eDP;
+
+   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
+   if (ret < 0)
+   return;
+
+   switch (dp->data->chip_type) {
+   case RK3399_EDP:
+   /*
+* For RK3399, VOP Lit must code the out mode to RGB888,
+* VOP Big must code the out mode to RGB10.
+*/
+   if (ret)
+   s->output_mode = ROCKCHIP_OUT_MODE_P888;
+   else
+   s->output_mode = ROCKCHIP_OUT_MODE_;
+   break;
+
+   default:
+   s->output_mode = ROCKCHIP_OUT_MODE_;
+   break;
+   }
 
return 0;
 }
@@ -377,6 +398,14 @@ static const struct dev_pm_ops rockchip_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
 };
 
+static const struct rockchip_dp_chip_data rk3399_edp = {
+   .lcdsel_grf_reg = 0x6250,
+   .lcdsel_big = 0,
+   .lcdsel_lit = BIT(5),
+   .lcdsel_mask = BIT(21),
+   .chip_type = RK3399_EDP,
+};
+
 static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = 0x025c,
.lcdsel_big = 0,
@@ -387,6 +416,7 @@ static const struct rockchip_dp_chip_data rk3288_dp = {
 
 static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = _dp },
+   {.compatible = "rockchip,rk3399-edp", .data = _edp },
{}
 };
 MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 06c0250..82b8135 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -20,6 +20,7 @@ enum analogix_dp_devtype {
 
 enum analogix_dp_sub_devtype {
RK3288_DP,
+   RK3399_EDP,
 };
 
 struct analogix_dp_plat_data {
-- 
1.9.1

[PATCH v2 01/10] drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP

[Yakir Yang]

Rename RK3288_DP marcos to ROCKCHIP_DP, prepare to add eDP
support for more Rockchip chips.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 6 +++---
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 2 +-
 include/drm/bridge/analogix_dp.h   | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7699597..4a1b3b8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1207,9 +1207,9 @@ static int analogix_dp_dt_parse_pdata(struct 
analogix_dp_device *dp)
struct video_info *video_info = >video_info;
 
switch (dp->plat_data->dev_type) {
-   case RK3288_DP:
+   case ROCKCHIP_DP:
/*
-* Like Rk3288 DisplayPort TRM indicate that "Main link
+* Like Rockchip DisplayPort TRM indicate that "Main link
 * containing 4 physical lanes of 2.7/1.62 Gbps/lane".
 */
video_info->max_link_rate = 0x0A;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 49205ef..931a76c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -74,7 +74,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
-   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP)) {
writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
@@ -244,7 +244,7 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
 
-   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP))
phy_pd_addr = ANALOGIX_DP_PD;
 
switch (block) {
@@ -448,7 +448,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
 
/* Disable AUX transaction H/W retry */
-   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP))
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
  AUX_HW_RETRY_COUNT_SEL(3) |
  AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 7f6a55c..2bc8a7e 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -270,7 +270,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
 
dp->plat_data.encoder = >encoder;
 
-   dp->plat_data.dev_type = RK3288_DP;
+   dp->plat_data.dev_type = ROCKCHIP_DP;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
 
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 25afb31..9e5d013 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -15,7 +15,7 @@
 
 enum analogix_dp_devtype {
EXYNOS_DP,
-   RK3288_DP,
+   ROCKCHIP_DP,
 };
 
 struct analogix_dp_plat_data {
-- 
1.9.1

[PATCH v2 03/10] drm/bridge: analogix_dp: correct the register bit define error in ANALOGIX_DP_PLL_REG_1

[Yakir Yang]

There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced
by commit bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special
registers setting").

The PHY PLL input clock source is selected by ANALOGIX_DP_PLL_REG_1
BIT 0, not BIT 1.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 337912b..88d56ad 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -163,8 +163,8 @@
 #define HSYNC_POLARITY_CFG (0x1 << 0)
 
 /* ANALOGIX_DP_PLL_REG_1 */
-#define REF_CLK_24M(0x1 << 1)
-#define REF_CLK_27M(0x0 << 1)
+#define REF_CLK_24M(0x1 << 0)
+#define REF_CLK_27M(0x0 << 0)
 
 /* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0 (0x0 << 6)
-- 
1.9.1

[PATCH v2 05/10] drm/rockchip: analogix_dp: add rk3399 eDP support

[Yakir Yang]

RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- rebase with drm-next, fix some conflicts

 .../bindings/display/bridge/analogix_dp.txt|  1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 34 --
 include/drm/bridge/analogix_dp.h   |  1 +
 4 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 4f2ba8c..4a0f4f7 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -5,6 +5,7 @@ Required properties for dp-controller:
platform specific such as:
 * "samsung,exynos5-dp"
 * "rockchip,rk3288-dp"
+* "rockchip,rk3399-edp"
-reg:
physical base address of the controller and length
of memory mapped region.
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index e832ff9..5ae55ca 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip RK3288 specific extensions to the Analogix Display Port
 
 
 Required properties:
-- compatible: "rockchip,rk3288-edp";
+- compatible: "rockchip,rk3288-edp" or "rockchip,rk3399-edp";
 
 - reg: physical base address of the controller and length
 
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 29c4105..d684c97 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -149,6 +149,8 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
 {
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
 
+   s->output_type = DRM_MODE_CONNECTOR_eDP;
+
/*
 * FIXME(Yakir): driver should configure the CRTC output video
 * mode with the display information which indicated the monitor
@@ -162,8 +164,27 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
 * But if I configure CTRC to RGBaaa, and eDP driver still keep
 * RGB666 input video mode, then screen would works prefect.
 */
-   s->output_mode = ROCKCHIP_OUT_MODE_;
-   s->output_type = DRM_MODE_CONNECTOR_eDP;
+
+   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
+   if (ret < 0)
+   return;
+
+   switch (dp->data->chip_type) {
+   case RK3399_EDP:
+   /*
+* For RK3399, VOP Lit must code the out mode to RGB888,
+* VOP Big must code the out mode to RGB10.
+*/
+   if (ret)
+   s->output_mode = ROCKCHIP_OUT_MODE_P888;
+   else
+   s->output_mode = ROCKCHIP_OUT_MODE_;
+   break;
+
+   default:
+   s->output_mode = ROCKCHIP_OUT_MODE_;
+   break;
+   }
 
return 0;
 }
@@ -377,6 +398,14 @@ static const struct dev_pm_ops rockchip_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
 };
 
+static const struct rockchip_dp_chip_data rk3399_edp = {
+   .lcdsel_grf_reg = 0x6250,
+   .lcdsel_big = 0,
+   .lcdsel_lit = BIT(5),
+   .lcdsel_mask = BIT(21),
+   .chip_type = RK3399_EDP,
+};
+
 static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = 0x025c,
.lcdsel_big = 0,
@@ -387,6 +416,7 @@ static const struct rockchip_dp_chip_data rk3288_dp = {
 
 static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = _dp },
+   {.compatible = "rockchip,rk3399-edp", .data = _edp },
{}
 };
 MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 06c0250..82b8135 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -20,6 +20,7 @@ enum analogix_dp_devtype {
 
 enum analogix_dp_sub_devtype {
RK3288_DP,
+   RK3399_EDP,
 };
 
 struct analogix_dp_plat_data {
-- 
1.9.1

[PATCH v2 04/10] drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit setting

[Yakir Yang]

As vendor document indicate, when REF_CLK bit set 0, then DP
phy's REF_CLK should switch to 24M source clock.

But due to IC PHY layout mistaken, some chips need to flip this
bit(like RK3288), and unfortunately they didn't indicate in the
DP version register. That's why we have to make this little hack.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- new patch in v2

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 6 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c   | 3 +++
 include/drm/bridge/analogix_dp.h  | 5 +
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 931a76c..31366bf 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -75,7 +75,11 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP)) {
-   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   reg = REF_CLK_24M;
+   if (dp->plat_data->subdev_type == RK3288_DP)
+   reg = ~reg & REF_CLK_MASK;
+
+   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 88d56ad..cdcc6c5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -165,6 +165,7 @@
 /* ANALOGIX_DP_PLL_REG_1 */
 #define REF_CLK_24M(0x1 << 0)
 #define REF_CLK_27M(0x0 << 0)
+#define REF_CLK_MASK   (0x1 << 0)
 
 /* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0 (0x0 << 6)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 260c43f..29c4105 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -41,6 +41,7 @@ struct rockchip_dp_chip_data {
u32 lcdsel_big;
u32 lcdsel_lit;
u32 lcdsel_mask;
+   u32 chip_type;
 };
 
 struct rockchip_dp_device {
@@ -281,6 +282,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.encoder = >encoder;
 
dp->plat_data.dev_type = ROCKCHIP_DP;
+   dp->plat_data.subdev_type = dp_data->chip_type;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
 
@@ -380,6 +382,7 @@ static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_big = 0,
.lcdsel_lit = BIT(5),
.lcdsel_mask = BIT(21),
+   .chip_type = RK3288_DP,
 };
 
 static const struct of_device_id rockchip_dp_dt_ids[] = {
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 9e5d013..06c0250 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -18,8 +18,13 @@ enum analogix_dp_devtype {
ROCKCHIP_DP,
 };
 
+enum analogix_dp_sub_devtype {
+   RK3288_DP,
+};
+
 struct analogix_dp_plat_data {
enum analogix_dp_devtype dev_type;
+   enum analogix_dp_sub_devtype subdev_type;
struct drm_panel *panel;
struct drm_encoder *encoder;
struct drm_connector *connector;
-- 
1.9.1

[PATCH v2 02/10] drm/rockchip: analogix_dp: split the lcdc select setting into device data

[Yakir Yang]

eDP controller need to declare which vop provide the video source,
and it's defined in GRF registers.

But different chips have different GRF register address, so we need to
create a device data to declare the GRF messages for each chips.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 35 ++---
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2bc8a7e..260c43f 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,11 +36,12 @@
 
 #define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
 
-/* dp grf register offset */
-#define GRF_SOC_CON60x025c
-#define GRF_EDP_LCD_SEL_MASKBIT(5)
-#define GRF_EDP_SEL_VOP_LIT BIT(5)
-#define GRF_EDP_SEL_VOP_BIG 0
+struct rockchip_dp_chip_data {
+   u32 lcdsel_grf_reg;
+   u32 lcdsel_big;
+   u32 lcdsel_lit;
+   u32 lcdsel_mask;
+};
 
 struct rockchip_dp_device {
struct drm_device*drm_dev;
@@ -51,6 +53,8 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
 
+   const struct rockchip_dp_chip_data *data;
+
struct analogix_dp_plat_data plat_data;
 };
 
@@ -119,13 +123,13 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
return;
 
if (ret)
-   val = GRF_EDP_SEL_VOP_LIT | (GRF_EDP_LCD_SEL_MASK << 16);
+   val = dp->data->lcdsel_lit | dp->data->lcdsel_mask;
else
-   val = GRF_EDP_SEL_VOP_BIG | (GRF_EDP_LCD_SEL_MASK << 16);
+   val = dp->data->lcdsel_big | dp->data->lcdsel_mask;
 
dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
 
-   ret = regmap_write(dp->grf, GRF_SOC_CON6, val);
+   ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
if (ret != 0) {
dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
return;
@@ -246,6 +250,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
void *data)
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+   const struct rockchip_dp_chip_data *dp_data;
struct drm_device *drm_dev = data;
int ret;
 
@@ -256,10 +261,15 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
 */
dev_set_drvdata(dev, NULL);
 
+   dp_data = of_device_get_match_data(dev);
+   if (!dp_data)
+   return -ENODEV;
+
ret = rockchip_dp_init(dp);
if (ret < 0)
return ret;
 
+   dp->data = dp_data;
dp->drm_dev = drm_dev;
 
ret = rockchip_dp_drm_create_encoder(dp);
@@ -365,8 +375,15 @@ static const struct dev_pm_ops rockchip_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
 };
 
+static const struct rockchip_dp_chip_data rk3288_dp = {
+   .lcdsel_grf_reg = 0x025c,
+   .lcdsel_big = 0,
+   .lcdsel_lit = BIT(5),
+   .lcdsel_mask = BIT(21),
+};
+
 static const struct of_device_id rockchip_dp_dt_ids[] = {
-   {.compatible = "rockchip,rk3288-dp",},
+   {.compatible = "rockchip,rk3288-dp", .data = _dp },
{}
 };
 MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
-- 
1.9.1

[PATCH v2 09/10] drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode

[Yakir Yang]

The hardware IC designed that VOP must output the RGB10 video format to
eDP contoller, and if eDP panel only support RGB8, then eDP contoller
should cut down the video data, not via VOP contoller, that's why we need
to hardcode the VOP output mode to RGA10 here.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- new patch in v2

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 910cceb..4b64964 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -170,17 +170,11 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
s->output_type = DRM_MODE_CONNECTOR_eDP;
 
/*
-* FIXME(Yakir): driver should configure the CRTC output video
-* mode with the display information which indicated the monitor
-* support colorimetry.
-*
-* But don't know why the CRTC driver seems could only output the
-* RGBaaa rightly. For example, if connect the "innolux,n116bge"
-* eDP screen, EDID would indicated that screen only accepted the
-* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
-* screen would show a blue picture (RGB888 show a green picture).
-* But if I configure CTRC to RGBaaa, and eDP driver still keep
-* RGB666 input video mode, then screen would works prefect.
+* The hardware IC designed that VOP must output the RGB10 video
+* format to eDP contoller, and if eDP panel only support RGB8,
+* then eDP contoller should cut down the video data, not via VOP
+* contoller, that's why we need to hardcode the VOP output mode
+* to RGA10 here.
 */
 
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
-- 
1.9.1

[PATCH v2 04/10] drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit setting

[Yakir Yang]

As vendor document indicate, when REF_CLK bit set 0, then DP
phy's REF_CLK should switch to 24M source clock.

But due to IC PHY layout mistaken, some chips need to flip this
bit(like RK3288), and unfortunately they didn't indicate in the
DP version register. That's why we have to make this little hack.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- new patch in v2

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 6 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c   | 3 +++
 include/drm/bridge/analogix_dp.h  | 5 +
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 931a76c..31366bf 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -75,7 +75,11 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP)) {
-   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   reg = REF_CLK_24M;
+   if (dp->plat_data->subdev_type == RK3288_DP)
+   reg = ~reg & REF_CLK_MASK;
+
+   writel(reg, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 88d56ad..cdcc6c5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -165,6 +165,7 @@
 /* ANALOGIX_DP_PLL_REG_1 */
 #define REF_CLK_24M(0x1 << 0)
 #define REF_CLK_27M(0x0 << 0)
+#define REF_CLK_MASK   (0x1 << 0)
 
 /* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0 (0x0 << 6)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 260c43f..29c4105 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -41,6 +41,7 @@ struct rockchip_dp_chip_data {
u32 lcdsel_big;
u32 lcdsel_lit;
u32 lcdsel_mask;
+   u32 chip_type;
 };
 
 struct rockchip_dp_device {
@@ -281,6 +282,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.encoder = >encoder;
 
dp->plat_data.dev_type = ROCKCHIP_DP;
+   dp->plat_data.subdev_type = dp_data->chip_type;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
 
@@ -380,6 +382,7 @@ static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_big = 0,
.lcdsel_lit = BIT(5),
.lcdsel_mask = BIT(21),
+   .chip_type = RK3288_DP,
 };
 
 static const struct of_device_id rockchip_dp_dt_ids[] = {
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 9e5d013..06c0250 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -18,8 +18,13 @@ enum analogix_dp_devtype {
ROCKCHIP_DP,
 };
 
+enum analogix_dp_sub_devtype {
+   RK3288_DP,
+};
+
 struct analogix_dp_plat_data {
enum analogix_dp_devtype dev_type;
+   enum analogix_dp_sub_devtype subdev_type;
struct drm_panel *panel;
struct drm_encoder *encoder;
struct drm_connector *connector;
-- 
1.9.1

[PATCH v2 02/10] drm/rockchip: analogix_dp: split the lcdc select setting into device data

[Yakir Yang]

eDP controller need to declare which vop provide the video source,
and it's defined in GRF registers.

But different chips have different GRF register address, so we need to
create a device data to declare the GRF messages for each chips.

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 35 ++---
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2bc8a7e..260c43f 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,11 +36,12 @@
 
 #define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
 
-/* dp grf register offset */
-#define GRF_SOC_CON60x025c
-#define GRF_EDP_LCD_SEL_MASKBIT(5)
-#define GRF_EDP_SEL_VOP_LIT BIT(5)
-#define GRF_EDP_SEL_VOP_BIG 0
+struct rockchip_dp_chip_data {
+   u32 lcdsel_grf_reg;
+   u32 lcdsel_big;
+   u32 lcdsel_lit;
+   u32 lcdsel_mask;
+};
 
 struct rockchip_dp_device {
struct drm_device*drm_dev;
@@ -51,6 +53,8 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
 
+   const struct rockchip_dp_chip_data *data;
+
struct analogix_dp_plat_data plat_data;
 };
 
@@ -119,13 +123,13 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
return;
 
if (ret)
-   val = GRF_EDP_SEL_VOP_LIT | (GRF_EDP_LCD_SEL_MASK << 16);
+   val = dp->data->lcdsel_lit | dp->data->lcdsel_mask;
else
-   val = GRF_EDP_SEL_VOP_BIG | (GRF_EDP_LCD_SEL_MASK << 16);
+   val = dp->data->lcdsel_big | dp->data->lcdsel_mask;
 
dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
 
-   ret = regmap_write(dp->grf, GRF_SOC_CON6, val);
+   ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
if (ret != 0) {
dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
return;
@@ -246,6 +250,7 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
void *data)
 {
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+   const struct rockchip_dp_chip_data *dp_data;
struct drm_device *drm_dev = data;
int ret;
 
@@ -256,10 +261,15 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
 */
dev_set_drvdata(dev, NULL);
 
+   dp_data = of_device_get_match_data(dev);
+   if (!dp_data)
+   return -ENODEV;
+
ret = rockchip_dp_init(dp);
if (ret < 0)
return ret;
 
+   dp->data = dp_data;
dp->drm_dev = drm_dev;
 
ret = rockchip_dp_drm_create_encoder(dp);
@@ -365,8 +375,15 @@ static const struct dev_pm_ops rockchip_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
 };
 
+static const struct rockchip_dp_chip_data rk3288_dp = {
+   .lcdsel_grf_reg = 0x025c,
+   .lcdsel_big = 0,
+   .lcdsel_lit = BIT(5),
+   .lcdsel_mask = BIT(21),
+};
+
 static const struct of_device_id rockchip_dp_dt_ids[] = {
-   {.compatible = "rockchip,rk3288-dp",},
+   {.compatible = "rockchip,rk3288-dp", .data = _dp },
{}
 };
 MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
-- 
1.9.1

[PATCH v2 09/10] drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode

[Yakir Yang]

The hardware IC designed that VOP must output the RGB10 video format to
eDP contoller, and if eDP panel only support RGB8, then eDP contoller
should cut down the video data, not via VOP contoller, that's why we need
to hardcode the VOP output mode to RGA10 here.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- new patch in v2

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 910cceb..4b64964 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -170,17 +170,11 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
s->output_type = DRM_MODE_CONNECTOR_eDP;
 
/*
-* FIXME(Yakir): driver should configure the CRTC output video
-* mode with the display information which indicated the monitor
-* support colorimetry.
-*
-* But don't know why the CRTC driver seems could only output the
-* RGBaaa rightly. For example, if connect the "innolux,n116bge"
-* eDP screen, EDID would indicated that screen only accepted the
-* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
-* screen would show a blue picture (RGB888 show a green picture).
-* But if I configure CTRC to RGBaaa, and eDP driver still keep
-* RGB666 input video mode, then screen would works prefect.
+* The hardware IC designed that VOP must output the RGB10 video
+* format to eDP contoller, and if eDP panel only support RGB8,
+* then eDP contoller should cut down the video data, not via VOP
+* contoller, that's why we need to hardcode the VOP output mode
+* to RGA10 here.
 */
 
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
-- 
1.9.1

[PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

[Yakir Yang]

Hi all,

This series have been posted about one month, still no comments, help here :(

RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.

Also same misc fix to analogix_dp driver:
- Hotplug invalid which report by Dan Carpenter
- Make panel detect to an optional action
- correct the register bit define error in ANALOGIX_DP_PLL_REG_1


Changes in v2:
- new patch in v2
- rebase with drm-next, fix some conflicts
- new patch in v2

Yakir Yang (10):
  drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP
  drm/rockchip: analogix_dp: split the lcdc select setting into device
data
  drm/bridge: analogix_dp: correct the register bit define error in
ANALOGIX_DP_PLL_REG_1
  drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit
setting
  drm/rockchip: analogix_dp: add rk3399 eDP support
  drm/rockchip: analogix_dp: make panel detect to an optional action
  drm/bridge: analogix_dp: introduce connector mode_valid callback to
plat driver
  drm/rockchip: analogix_dp: correct the connector display color format
and bpc
  drm/rockchip: analogix_dp: update the comments about why need to
hardcode VOP output mode
  drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

 .../bindings/display/bridge/analogix_dp.txt|   1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  19 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  12 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   5 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 157 ++---
 include/drm/bridge/analogix_dp.h   |  10 ++
 8 files changed, 152 insertions(+), 62 deletions(-)

-- 
1.9.1

[PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

[Yakir Yang]

Hi all,

This series have been posted about one month, still no comments, help here :(

RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.

Also same misc fix to analogix_dp driver:
- Hotplug invalid which report by Dan Carpenter
- Make panel detect to an optional action
- correct the register bit define error in ANALOGIX_DP_PLL_REG_1


Changes in v2:
- new patch in v2
- rebase with drm-next, fix some conflicts
- new patch in v2

Yakir Yang (10):
  drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP
  drm/rockchip: analogix_dp: split the lcdc select setting into device
data
  drm/bridge: analogix_dp: correct the register bit define error in
ANALOGIX_DP_PLL_REG_1
  drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit
setting
  drm/rockchip: analogix_dp: add rk3399 eDP support
  drm/rockchip: analogix_dp: make panel detect to an optional action
  drm/bridge: analogix_dp: introduce connector mode_valid callback to
plat driver
  drm/rockchip: analogix_dp: correct the connector display color format
and bpc
  drm/rockchip: analogix_dp: update the comments about why need to
hardcode VOP output mode
  drm/bridge: analogix_dp: fix no drm hpd event when panel plug in

 .../bindings/display/bridge/analogix_dp.txt|   1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  19 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  12 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   5 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 157 ++---
 include/drm/bridge/analogix_dp.h   |  10 ++
 8 files changed, 152 insertions(+), 62 deletions(-)

-- 
1.9.1

Re: [PATCH v2] cpufreq: stats: Walk online CPUs with CPU offline/online locked

[Viresh Kumar]

On 23-05-16, 22:47, Rafael J. Wysocki wrote:
> Assuming that the loops are over online CPUs and not over possible
> CPUs I suppose?

I wasn't focussing on that loop lately but the policy->rwsem :)

> Anyway, if you are talking about the code without the patch (which I
> guess is the case), the reason why it is racy is because, if
> cpufreq_stats_init() runs in parallel with CPU online, the CPU going
> online may be missed by it.  To my eyes that happens if
> cpufreq_online() has already advanced beyond the point where the
> notifier would have been invoked, but hasn't returned yet when the
> for_each_online_cpu() loop in cpufreq_stats_init() is executed.

Yes. That's a race we need to fix. I agree.

> Worse yet, if a CPU goes offline when cpufreq_stats_exit() is running
> and that happens exactly between the notifier unregistration and the
> for_each_online_cpu() loop, the stats table will never be freed for
> that CPU (say the policy isn't shared).

Same here.

> Switching over to loops over possible CPUs doesn't address those races
> (at least not the second one), and I'm not really sure why I thought
> it would address them, but adding CPU online/offline locking to
> cpufreq_stats_init/exit() can address them, so it looks like the very
> first version of my patch (ie.
> https://patchwork.kernel.org/patch/9128509/) was actually correct,
> because it didn't put too much code under the CPU offline/online
> locking. :-)

Well, I think there is one more way of getting all this fixed, which may
eventually look much more cleaner.

What if we update cpufreq core instead of stats with something like this:

-8<-

From: Viresh Kumar 
Date: Tue, 24 May 2016 10:16:25 +0530
Subject: [PATCH] cpufreq: Initiate notifiers for existing policy

Races are possible in the init/exit paths of the cpufreq-stats layer,
which may lead to 'stats' sysfs directory not getting created or removed
for some of the policies. This can happen while the policy is getting
created while cpufreq_stats_init/exit() are getting called.

To avoid adding unnecessary locks in the init/exit paths of the
cpufreq-stats layer, update the policy notifier register/unregister
routines to send notifications for any existing cpufreq policies.

Also make sure (with help of cpufreq_driver_lock) that
CPUFREQ_CREATE/REMOVE notifiers aren't getting issued in parallel from
the policy creation/removal paths.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c   | 35 +-
 drivers/cpufreq/cpufreq_stats.c | 55 ++---
 2 files changed, 41 insertions(+), 49 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index c3f950f0e5f0..90f4bf03701d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1269,10 +1269,10 @@ static int cpufreq_online(unsigned int cpu)
ret = cpufreq_add_dev_interface(policy);
if (ret)
goto out_exit_policy;
+   write_lock_irqsave(_driver_lock, flags);
blocking_notifier_call_chain(_policy_notifier_list,
CPUFREQ_CREATE_POLICY, policy);
 
-   write_lock_irqsave(_driver_lock, flags);
list_add(>policy_list, _policy_list);
write_unlock_irqrestore(_driver_lock, flags);
}
@@ -1728,6 +1728,8 @@ EXPORT_SYMBOL_GPL(cpufreq_get_driver_data);
  */
 int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 {
+   struct cpufreq_policy *policy;
+   unsigned long flags;
int ret;
 
if (cpufreq_disabled())
@@ -1751,8 +1753,28 @@ int cpufreq_register_notifier(struct notifier_block *nb, 
unsigned int list)
mutex_unlock(_fast_switch_lock);
break;
case CPUFREQ_POLICY_NOTIFIER:
+   write_lock_irqsave(_driver_lock, flags);
+
+   /* Notify about all existing policies */
+   for_each_policy(policy) {
+   nb->notifier_call(nb, CPUFREQ_CREATE_POLICY,
+   policy);
+   if (policy_is_inactive(policy))
+   continue;
+
+   nb->notifier_call(nb, CPUFREQ_START, policy);
+   }
+
ret = blocking_notifier_chain_register(
_policy_notifier_list, nb);
+   if (ret) {
+   /* Notify about all existing policies */
+   for_each_policy(policy) {
+   nb->notifier_call(nb, CPUFREQ_REMOVE_POLICY,
+ policy);
+   }
+   }
+   write_unlock_irqrestore(_driver_lock, flags);
break;
default:
ret = -EINVAL;
@@ -1774,6 +1796,8 

Re: [PATCH v2] cpufreq: stats: Walk online CPUs with CPU offline/online locked

[Viresh Kumar]

On 23-05-16, 22:47, Rafael J. Wysocki wrote:
> Assuming that the loops are over online CPUs and not over possible
> CPUs I suppose?

I wasn't focussing on that loop lately but the policy->rwsem :)

> Anyway, if you are talking about the code without the patch (which I
> guess is the case), the reason why it is racy is because, if
> cpufreq_stats_init() runs in parallel with CPU online, the CPU going
> online may be missed by it.  To my eyes that happens if
> cpufreq_online() has already advanced beyond the point where the
> notifier would have been invoked, but hasn't returned yet when the
> for_each_online_cpu() loop in cpufreq_stats_init() is executed.

Yes. That's a race we need to fix. I agree.

> Worse yet, if a CPU goes offline when cpufreq_stats_exit() is running
> and that happens exactly between the notifier unregistration and the
> for_each_online_cpu() loop, the stats table will never be freed for
> that CPU (say the policy isn't shared).

Same here.

> Switching over to loops over possible CPUs doesn't address those races
> (at least not the second one), and I'm not really sure why I thought
> it would address them, but adding CPU online/offline locking to
> cpufreq_stats_init/exit() can address them, so it looks like the very
> first version of my patch (ie.
> https://patchwork.kernel.org/patch/9128509/) was actually correct,
> because it didn't put too much code under the CPU offline/online
> locking. :-)

Well, I think there is one more way of getting all this fixed, which may
eventually look much more cleaner.

What if we update cpufreq core instead of stats with something like this:

-8<-

From: Viresh Kumar 
Date: Tue, 24 May 2016 10:16:25 +0530
Subject: [PATCH] cpufreq: Initiate notifiers for existing policy

Races are possible in the init/exit paths of the cpufreq-stats layer,
which may lead to 'stats' sysfs directory not getting created or removed
for some of the policies. This can happen while the policy is getting
created while cpufreq_stats_init/exit() are getting called.

To avoid adding unnecessary locks in the init/exit paths of the
cpufreq-stats layer, update the policy notifier register/unregister
routines to send notifications for any existing cpufreq policies.

Also make sure (with help of cpufreq_driver_lock) that
CPUFREQ_CREATE/REMOVE notifiers aren't getting issued in parallel from
the policy creation/removal paths.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c   | 35 +-
 drivers/cpufreq/cpufreq_stats.c | 55 ++---
 2 files changed, 41 insertions(+), 49 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index c3f950f0e5f0..90f4bf03701d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1269,10 +1269,10 @@ static int cpufreq_online(unsigned int cpu)
ret = cpufreq_add_dev_interface(policy);
if (ret)
goto out_exit_policy;
+   write_lock_irqsave(_driver_lock, flags);
blocking_notifier_call_chain(_policy_notifier_list,
CPUFREQ_CREATE_POLICY, policy);
 
-   write_lock_irqsave(_driver_lock, flags);
list_add(>policy_list, _policy_list);
write_unlock_irqrestore(_driver_lock, flags);
}
@@ -1728,6 +1728,8 @@ EXPORT_SYMBOL_GPL(cpufreq_get_driver_data);
  */
 int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list)
 {
+   struct cpufreq_policy *policy;
+   unsigned long flags;
int ret;
 
if (cpufreq_disabled())
@@ -1751,8 +1753,28 @@ int cpufreq_register_notifier(struct notifier_block *nb, 
unsigned int list)
mutex_unlock(_fast_switch_lock);
break;
case CPUFREQ_POLICY_NOTIFIER:
+   write_lock_irqsave(_driver_lock, flags);
+
+   /* Notify about all existing policies */
+   for_each_policy(policy) {
+   nb->notifier_call(nb, CPUFREQ_CREATE_POLICY,
+   policy);
+   if (policy_is_inactive(policy))
+   continue;
+
+   nb->notifier_call(nb, CPUFREQ_START, policy);
+   }
+
ret = blocking_notifier_chain_register(
_policy_notifier_list, nb);
+   if (ret) {
+   /* Notify about all existing policies */
+   for_each_policy(policy) {
+   nb->notifier_call(nb, CPUFREQ_REMOVE_POLICY,
+ policy);
+   }
+   }
+   write_unlock_irqrestore(_driver_lock, flags);
break;
default:
ret = -EINVAL;
@@ -1774,6 +1796,8 @@ EXPORT_SYMBOL(cpufreq_register_notifier);
  */

Re: linux-next: Tree for May 17

[Xiong Zhou]

Hi Stephen,

On Mon, May 23, 2016 at 4:37 PM, Stephen Rothwell  wrote:
> Hi Xiong,
>
> On Mon, 23 May 2016 16:13:28 +0800 Xiong Zhou  wrote:
>>
>> hi,
>>
>> On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell  
>> wrote:
>> >
>> > I have created today's linux-next tree at
>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> > (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
>>
>> Patches after 0516 are not there.
>>
>> i'm chasing an oom issue between 0516 and 0518 trees while missed
>> 0517 tag, so is the patch file the only way to get there trying 0517 tree?
>
> They are there, just the version numbering puts them out of order in the
> page listing - they appear before patch-v4.6-rc1-next-20160327.gz

Ya, my bad, i found them.

>
> All the (recent) tags are in the git tree as well, of course.

Yes! git fetch -t saved my mess git repo.

Thank you very much!

--
Xiong


> --
> Cheers,
> Stephen Rothwell

Re: linux-next: Tree for May 17

[Xiong Zhou]

Hi Stephen,

On Mon, May 23, 2016 at 4:37 PM, Stephen Rothwell  wrote:
> Hi Xiong,
>
> On Mon, 23 May 2016 16:13:28 +0800 Xiong Zhou  wrote:
>>
>> hi,
>>
>> On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell  
>> wrote:
>> >
>> > I have created today's linux-next tree at
>> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> > (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
>>
>> Patches after 0516 are not there.
>>
>> i'm chasing an oom issue between 0516 and 0518 trees while missed
>> 0517 tag, so is the patch file the only way to get there trying 0517 tree?
>
> They are there, just the version numbering puts them out of order in the
> page listing - they appear before patch-v4.6-rc1-next-20160327.gz

Ya, my bad, i found them.

>
> All the (recent) tags are in the git tree as well, of course.

Yes! git fetch -t saved my mess git repo.

Thank you very much!

--
Xiong


> --
> Cheers,
> Stephen Rothwell

Re: [PATCH 2/4] phy: rockchip-emmc: configure frequency range and drive impedance

[Doug Anderson]

Hi,

On Fri, May 13, 2016 at 11:46 AM, Doug Anderson  wrote:
>> Per the commit msg, signal may vary from board to board, so I guess
>> 50ohm may not always be the best selection?
>
> Starting out with something sane like 50 ohms seems like it makes
> sense for now.  It's OK to start with a default for now to get things
> basically working and then add device tree support once we have a
> second user.
>
>
> When we're ready to make this more generic, IMHO we might consider
> having the PHY implement the pinctrl API and officially be a pin
> controller and we use those bindings.  We are controlling pins so
> using the pinctrl API seems like it might make sense?
>
> I _think_ that perhaps what we're specifying here is actually slew
> rate, but feel free to correct me if I'm wrong.  It looks as if "drive
> strength" is supposed to be specified in terms of mA and the docs I
> find show that we're actually controlling how fast the pins will
> toggle.
>
> I'm not 100% certain I know how the pinctrl bindings apply in this
> case (maybe Heiko has ideas, or maybe we should send a proposal to
> Linus W?), but from the bindings they look like they offer some
> flexibility.
>
> Maybe this would look like below (or maybe you need some extra sub-nodes)
>
>sdhci: sdhci@fe33 {
>compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
>reg = <0x0 0xfe33 0x0 0x1>;
>interrupts = ;
>clocks = < SCLK_EMMC>, < ACLK_EMMC>;
>clock-names = "clk_xin", "clk_ahb";
>assigned-clocks = < SCLK_EMMC>;
>assigned-clock-rates = <2>;
>phys = <_phy>;
>phy-names = "phy_arasan";
>pinctrl-names = "default";
>pinctrl-0 = <_emmc_slew_rate_x1_00>;
>status = "disabled";
>};
>
>emmc_phy: phy@f780 {
>compatible = "rockchip,rk3399-emmc-phy";
>reg = <0xf780 0x20>;
>#phy-cells = <0>;
>status = "disabled";
>
>pcfg_emmc_slew_rate_x1_00: pcfg-emmc-slew-rate-x1-00 {
>slew-rate = <100>;
>};
>pcfg_emmc_slew_rate_x1_50: pcfg-emmc-slew-rate-x1-50 {
>slew-rate = <150>;
>};
>pcfg_emmc_slew_rate_x0_75: pcfg-emmc-slew-rate-x0-75 {
>slew-rate = <75>;
>};
>pcfg_emmc_slew_rate_x0_50: pcfg-emmc-slew-rate-x0-50 {
>slew-rate = <50>;
>};
>pcfg_emmc_slew_rate_x1_20: pcfg-emmc-slew-rate-x1-20 {
>slew-rate = <120>;
>};
>pcfg_emmc_slew_rate_x1_20: pcfg-emmc-slew-rate-x1-20 {
>slew-rate = <120>;
>};
>};
>
> The nice thing about using the pinctrl API is that:
>
> * It allows us to _also_ control pullups / pulldowns.  We probably
> want to control those also since some boards may use external pullups
> and others may want to use the internal ones.
>
> * If SDHCI needs to dynamically adjust things (like turning on pulls,
> adjusting drive strengths, etc) it can do it in a sane API.

Note that I still believe that we could land the 50 Ohm first (AKA
land the patch Brian posted), but I'm also convinced that my pinctrl
proposal above is not a good idea for the way to move forward, at
least in terms of the "driver strength" part.  Specifically it seems
like the 50 Ohm / 33 Ohm / 66 Ohm / 100 Ohm / 40 Ohm is a concept from
eMMC 5.0 and probably doesn't fit to pinctrl.

I also _think_ it needs to be matched against what's available from
the card (card->drive_strength) and the card needs to be told about
it, but I could be wrong about that.



-Doug

Re: [PATCH 2/4] phy: rockchip-emmc: configure frequency range and drive impedance

[Doug Anderson]

Hi,

On Fri, May 13, 2016 at 11:46 AM, Doug Anderson  wrote:
>> Per the commit msg, signal may vary from board to board, so I guess
>> 50ohm may not always be the best selection?
>
> Starting out with something sane like 50 ohms seems like it makes
> sense for now.  It's OK to start with a default for now to get things
> basically working and then add device tree support once we have a
> second user.
>
>
> When we're ready to make this more generic, IMHO we might consider
> having the PHY implement the pinctrl API and officially be a pin
> controller and we use those bindings.  We are controlling pins so
> using the pinctrl API seems like it might make sense?
>
> I _think_ that perhaps what we're specifying here is actually slew
> rate, but feel free to correct me if I'm wrong.  It looks as if "drive
> strength" is supposed to be specified in terms of mA and the docs I
> find show that we're actually controlling how fast the pins will
> toggle.
>
> I'm not 100% certain I know how the pinctrl bindings apply in this
> case (maybe Heiko has ideas, or maybe we should send a proposal to
> Linus W?), but from the bindings they look like they offer some
> flexibility.
>
> Maybe this would look like below (or maybe you need some extra sub-nodes)
>
>sdhci: sdhci@fe33 {
>compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
>reg = <0x0 0xfe33 0x0 0x1>;
>interrupts = ;
>clocks = < SCLK_EMMC>, < ACLK_EMMC>;
>clock-names = "clk_xin", "clk_ahb";
>assigned-clocks = < SCLK_EMMC>;
>assigned-clock-rates = <2>;
>phys = <_phy>;
>phy-names = "phy_arasan";
>pinctrl-names = "default";
>pinctrl-0 = <_emmc_slew_rate_x1_00>;
>status = "disabled";
>};
>
>emmc_phy: phy@f780 {
>compatible = "rockchip,rk3399-emmc-phy";
>reg = <0xf780 0x20>;
>#phy-cells = <0>;
>status = "disabled";
>
>pcfg_emmc_slew_rate_x1_00: pcfg-emmc-slew-rate-x1-00 {
>slew-rate = <100>;
>};
>pcfg_emmc_slew_rate_x1_50: pcfg-emmc-slew-rate-x1-50 {
>slew-rate = <150>;
>};
>pcfg_emmc_slew_rate_x0_75: pcfg-emmc-slew-rate-x0-75 {
>slew-rate = <75>;
>};
>pcfg_emmc_slew_rate_x0_50: pcfg-emmc-slew-rate-x0-50 {
>slew-rate = <50>;
>};
>pcfg_emmc_slew_rate_x1_20: pcfg-emmc-slew-rate-x1-20 {
>slew-rate = <120>;
>};
>pcfg_emmc_slew_rate_x1_20: pcfg-emmc-slew-rate-x1-20 {
>slew-rate = <120>;
>};
>};
>
> The nice thing about using the pinctrl API is that:
>
> * It allows us to _also_ control pullups / pulldowns.  We probably
> want to control those also since some boards may use external pullups
> and others may want to use the internal ones.
>
> * If SDHCI needs to dynamically adjust things (like turning on pulls,
> adjusting drive strengths, etc) it can do it in a sane API.

Note that I still believe that we could land the 50 Ohm first (AKA
land the patch Brian posted), but I'm also convinced that my pinctrl
proposal above is not a good idea for the way to move forward, at
least in terms of the "driver strength" part.  Specifically it seems
like the 50 Ohm / 33 Ohm / 66 Ohm / 100 Ohm / 40 Ohm is a concept from
eMMC 5.0 and probably doesn't fit to pinctrl.

I also _think_ it needs to be matched against what's available from
the card (card->drive_strength) and the card needs to be told about
it, but I could be wrong about that.



-Doug

Re: [RFC PATCH 4/9] sched/fair: Rename variable names for sched averages

[Yuyang Du]

On Mon, May 16, 2016 at 02:59:29AM +0800, Yuyang Du wrote:
> -#define LOAD_AVG_MAX_N 347 /* number of full periods to produce LOAD_AVG_MAX 
> */
> +#define SCHED_AVG_MAX_N 345  /* number of full periods to produce 
> SCHED_AVG_MAX */

Sorry, I changed it back when I rebased it, my bad.

Re: [RFC PATCH 4/9] sched/fair: Rename variable names for sched averages

[Yuyang Du]

On Mon, May 16, 2016 at 02:59:29AM +0800, Yuyang Du wrote:
> -#define LOAD_AVG_MAX_N 347 /* number of full periods to produce LOAD_AVG_MAX 
> */
> +#define SCHED_AVG_MAX_N 345  /* number of full periods to produce 
> SCHED_AVG_MAX */

Sorry, I changed it back when I rebased it, my bad.

[GIT PULL] MTD updates for v4.7

[Brian Norris]

Hi Linus,

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20160523

for you to fetch changes up to e5366a266a8cd4cd6b0fe66876462cca2e1c6a89:

  mtd: spi-nor: support GigaDevice gd25lq64c (2016-05-10 15:44:18 -0700)


MTD updates for v4.7:

First cycle with Boris as NAND maintainer! Many (most) bullets stolen from him.

Generic:

 * Migrated NAND LED trigger to be a generic MTD trigger

NAND:

 * Introduction of the "ECC algorithm" concept, to avoid overloading the ECC
   mode field too much more
 * Replaced the nand_ecclayout infrastructure with something a little more
   flexible (finally!) and future proof
 * Rework of the OMAP GPMC and NAND drivers; the TI folks pulled some of
   this into their own tree as well
 * Prepare the sunxi NAND driver to receive DMA support
 * Handle bitflips in erased pages on GPMI revisions that do not support
   this in hardware.

SPI NOR:

 * Start using the spi_flash_read() API for SPI drivers that support it (i.e.,
   SPI drivers with special memory-mapped flash modes)

And other small scattered improvments.


Arnd Bergmann (1):
  mtd: avoid stack overflow in MTD CFI code

Boris Brezillon (85):
  Merge branch 'for-v4.7/gpmc-mtd-common' of github.com:rogerq/linux into 
nand/next
  Merge branch 'mtd-nand-trigger' of 
git://git.kernel.org/.../j.anaszewski/linux-leds into nand/next
  mtd: nand: atmel: correct bitflips in erased pages for pre-sama5d4 SoCs
  mtd: nand: document the NAND controller/NAND chip DT representation
  mtd: nand: remove unneeded of_mtd.h inclusions
  mtd: nand: omap2: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: brcm: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: atmel: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: pxa3xx: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: sunxi: fix call order in sunxi_nand_chip_init()
  mtd: nand: sunxi: fix clk rate calculation
  mtd: nand: sunxi: fix EDO mode selection
  mtd: nand: sunxi: adapt clk_rate to tWB, tADL, tWHR and tRHW timings
  mtd: nand: export default read/write oob functions
  mtd: nand: sunxi: implement ->read_oob()/->write_oob()
  mtd: nand: sunxi: implement ->read_subpage()
  mtd: nand: sunxi: improve ->cmd_ctrl() function
  mtd: nand: sunxi: let the NAND controller control the CE line
  mtd: nand: sunxi: fix the NFC_ECC_ERR_CNT() macro
  mtd: nand: sunxi: fix NFC_CTL setting
  mtd: nand: sunxi: disable clks on device removal
  mtd: nand: enable ECC pipelining
  mtd: nand: sunxi: fix ->dev_ready() implementation
  mtd: nand: sunxi: make use of readl_poll_timeout()
  mtd: nand: sunxi: poll for events instead of using interrupts
  mtd: nand: sunxi: move some ECC related operations to their own functions
  mtd: nand: sunxi: make OOB retrieval optional
  mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers
  mtd: add mtd_ooblayout_xxx() helper functions
  mtd: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: core: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: atmel: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: qcom: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: onenand: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: add mtd_set_ecclayout() helper function
  mtd: use mtd_set_ecclayout() where appropriate
  mtd: nand: use mtd_set_ecclayout() where appropriate
  mtd: onenand: use mtd_set_ecclayout() where appropriate
  mtd: docg3: use mtd_set_ecclayout() where appropriate
  mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition
  mtd: docg3: switch to mtd_ooblayout_ops
  mtd: nand: implement the default mtd_ooblayout_ops
  mtd: nand: bch: switch to mtd_ooblayout_ops
  mtd: nand: sharpsl: switch to mtd_ooblayout_ops
  mtd: nand: jz4740: switch to mtd_ooblayout_ops
  mtd: nand: atmel: switch to mtd_ooblayout_ops
  mtd: nand: bf5xx: switch to mtd_ooblayout_ops
  mtd: nand: brcm: switch to mtd_ooblayout_ops
  mtd: nand: cafe: switch to mtd_ooblayout_ops
  mtd: nand: davinci: switch to mtd_ooblayout_ops
  mtd: nand: denali: switch to mtd_ooblayout_ops
  mtd: nand: diskonchip: switch to mtd_ooblayout_ops
 

[GIT PULL] MTD updates for v4.7

[Brian Norris]

Hi Linus,

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20160523

for you to fetch changes up to e5366a266a8cd4cd6b0fe66876462cca2e1c6a89:

  mtd: spi-nor: support GigaDevice gd25lq64c (2016-05-10 15:44:18 -0700)


MTD updates for v4.7:

First cycle with Boris as NAND maintainer! Many (most) bullets stolen from him.

Generic:

 * Migrated NAND LED trigger to be a generic MTD trigger

NAND:

 * Introduction of the "ECC algorithm" concept, to avoid overloading the ECC
   mode field too much more
 * Replaced the nand_ecclayout infrastructure with something a little more
   flexible (finally!) and future proof
 * Rework of the OMAP GPMC and NAND drivers; the TI folks pulled some of
   this into their own tree as well
 * Prepare the sunxi NAND driver to receive DMA support
 * Handle bitflips in erased pages on GPMI revisions that do not support
   this in hardware.

SPI NOR:

 * Start using the spi_flash_read() API for SPI drivers that support it (i.e.,
   SPI drivers with special memory-mapped flash modes)

And other small scattered improvments.


Arnd Bergmann (1):
  mtd: avoid stack overflow in MTD CFI code

Boris Brezillon (85):
  Merge branch 'for-v4.7/gpmc-mtd-common' of github.com:rogerq/linux into 
nand/next
  Merge branch 'mtd-nand-trigger' of 
git://git.kernel.org/.../j.anaszewski/linux-leds into nand/next
  mtd: nand: atmel: correct bitflips in erased pages for pre-sama5d4 SoCs
  mtd: nand: document the NAND controller/NAND chip DT representation
  mtd: nand: remove unneeded of_mtd.h inclusions
  mtd: nand: omap2: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: brcm: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: atmel: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: pxa3xx: rely on generic DT parsing done in nand_scan_ident()
  mtd: nand: sunxi: fix call order in sunxi_nand_chip_init()
  mtd: nand: sunxi: fix clk rate calculation
  mtd: nand: sunxi: fix EDO mode selection
  mtd: nand: sunxi: adapt clk_rate to tWB, tADL, tWHR and tRHW timings
  mtd: nand: export default read/write oob functions
  mtd: nand: sunxi: implement ->read_oob()/->write_oob()
  mtd: nand: sunxi: implement ->read_subpage()
  mtd: nand: sunxi: improve ->cmd_ctrl() function
  mtd: nand: sunxi: let the NAND controller control the CE line
  mtd: nand: sunxi: fix the NFC_ECC_ERR_CNT() macro
  mtd: nand: sunxi: fix NFC_CTL setting
  mtd: nand: sunxi: disable clks on device removal
  mtd: nand: enable ECC pipelining
  mtd: nand: sunxi: fix ->dev_ready() implementation
  mtd: nand: sunxi: make use of readl_poll_timeout()
  mtd: nand: sunxi: poll for events instead of using interrupts
  mtd: nand: sunxi: move some ECC related operations to their own functions
  mtd: nand: sunxi: make OOB retrieval optional
  mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers
  mtd: add mtd_ooblayout_xxx() helper functions
  mtd: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: core: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: atmel: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: qcom: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: onenand: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: add mtd_set_ecclayout() helper function
  mtd: use mtd_set_ecclayout() where appropriate
  mtd: nand: use mtd_set_ecclayout() where appropriate
  mtd: onenand: use mtd_set_ecclayout() where appropriate
  mtd: docg3: use mtd_set_ecclayout() where appropriate
  mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition
  mtd: docg3: switch to mtd_ooblayout_ops
  mtd: nand: implement the default mtd_ooblayout_ops
  mtd: nand: bch: switch to mtd_ooblayout_ops
  mtd: nand: sharpsl: switch to mtd_ooblayout_ops
  mtd: nand: jz4740: switch to mtd_ooblayout_ops
  mtd: nand: atmel: switch to mtd_ooblayout_ops
  mtd: nand: bf5xx: switch to mtd_ooblayout_ops
  mtd: nand: brcm: switch to mtd_ooblayout_ops
  mtd: nand: cafe: switch to mtd_ooblayout_ops
  mtd: nand: davinci: switch to mtd_ooblayout_ops
  mtd: nand: denali: switch to mtd_ooblayout_ops
  mtd: nand: diskonchip: switch to mtd_ooblayout_ops
 

Re: crosstool builds - https://www.kernel.org/pub/tools/crosstool/

[Peter Hurley]

Hi Jon,

On 05/19/2016 08:48 PM, Jon Masters wrote:
> Hi Tony,
> 
> I'm wondering whether you know of anyone who has picked up where you
> left off, building cross toolchains for various and sundry alternative
> architectures? I wanted to download an IA64 compiler recently (really)
> and noticed that the most recent builds were against GCC 4.6.3.

Someone's been making them.

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/

arm64
alpha
arm = gnueabi
parisc = hppa
parisc64 = hppa64
mips
mips64
powerpc
powerpc64
sparc
sparc64
s390
...

Regards,
Peter Hurley

Re: crosstool builds - https://www.kernel.org/pub/tools/crosstool/

[Peter Hurley]

Hi Jon,

On 05/19/2016 08:48 PM, Jon Masters wrote:
> Hi Tony,
> 
> I'm wondering whether you know of anyone who has picked up where you
> left off, building cross toolchains for various and sundry alternative
> architectures? I wanted to download an IA64 compiler recently (really)
> and noticed that the most recent builds were against GCC 4.6.3.

Someone's been making them.

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/

arm64
alpha
arm = gnueabi
parisc = hppa
parisc64 = hppa64
mips
mips64
powerpc
powerpc64
sparc
sparc64
s390
...

Regards,
Peter Hurley

Re: [RFC PATCH 0/9] Clean up and optimize sched averages

[Yuyang Du]

Hi Peter,

Could you give this a look?

Thanks,
Yuyang

On Mon, May 16, 2016 at 02:59:25AM +0800, Yuyang Du wrote:
> Hi Peter,
> 
> Continue the left patches in this series. I realized some patches should
> need thorough discussion (finally), so this post is marked RFC.
> 
>  - For LOAD_AVG_MAX_N, I am OK to stick to the old value, but it is worthwhile
>to get it cleared to the true value.
> 
>  - About the renames, I noticed there is an existing sched_avg_update(), but
>anyway, please NAK the renames you don't want, hopefully not all, ;)
> 
>  - Removing scale_load_down() for load_avg may have some unknown 
> ramifications,
>is it worth trying?
> 
> The previous post is at: 
> http://thread.gmane.org/gmane.linux.kernel/2214387/focus=2218488
> 
> Thanks,
> Yuyang
> 
> --
> 
> Yuyang Du (9):
>   sched/fair: Chance LOAD_AVG_MAX_N from 345 to 347
>   documentation: Add scheduler/sched-avg.txt
>   sched/fair: Add static to remove_entity_load_avg()
>   sched/fair: Rename variable names for sched averages
>   sched/fair: Change the variable to hold the number of periods to
> 32-bit
>   sched/fair: Add __always_inline compiler attribute to
> __accumulate_sum()
>   sched/fair: Optimize __update_sched_avg()
>   sched/fair: Remove scale_load_down() for load_avg
>   sched/fair: Rename scale_load() and scale_load_down()
> 
>  Documentation/scheduler/sched-avg.txt |   94 
>  include/linux/sched.h |   21 +-
>  kernel/sched/core.c   |8 +-
>  kernel/sched/fair.c   |  382 
> +
>  kernel/sched/sched.h  |   18 +-
>  5 files changed, 317 insertions(+), 206 deletions(-)
>  create mode 100644 Documentation/scheduler/sched-avg.txt
> 
> -- 
> 1.7.9.5

Re: [RFC PATCH 0/9] Clean up and optimize sched averages

[Yuyang Du]

Hi Peter,

Could you give this a look?

Thanks,
Yuyang

On Mon, May 16, 2016 at 02:59:25AM +0800, Yuyang Du wrote:
> Hi Peter,
> 
> Continue the left patches in this series. I realized some patches should
> need thorough discussion (finally), so this post is marked RFC.
> 
>  - For LOAD_AVG_MAX_N, I am OK to stick to the old value, but it is worthwhile
>to get it cleared to the true value.
> 
>  - About the renames, I noticed there is an existing sched_avg_update(), but
>anyway, please NAK the renames you don't want, hopefully not all, ;)
> 
>  - Removing scale_load_down() for load_avg may have some unknown 
> ramifications,
>is it worth trying?
> 
> The previous post is at: 
> http://thread.gmane.org/gmane.linux.kernel/2214387/focus=2218488
> 
> Thanks,
> Yuyang
> 
> --
> 
> Yuyang Du (9):
>   sched/fair: Chance LOAD_AVG_MAX_N from 345 to 347
>   documentation: Add scheduler/sched-avg.txt
>   sched/fair: Add static to remove_entity_load_avg()
>   sched/fair: Rename variable names for sched averages
>   sched/fair: Change the variable to hold the number of periods to
> 32-bit
>   sched/fair: Add __always_inline compiler attribute to
> __accumulate_sum()
>   sched/fair: Optimize __update_sched_avg()
>   sched/fair: Remove scale_load_down() for load_avg
>   sched/fair: Rename scale_load() and scale_load_down()
> 
>  Documentation/scheduler/sched-avg.txt |   94 
>  include/linux/sched.h |   21 +-
>  kernel/sched/core.c   |8 +-
>  kernel/sched/fair.c   |  382 
> +
>  kernel/sched/sched.h  |   18 +-
>  5 files changed, 317 insertions(+), 206 deletions(-)
>  create mode 100644 Documentation/scheduler/sched-avg.txt
> 
> -- 
> 1.7.9.5

Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity

[Yuyang Du]

On Thu, May 19, 2016 at 04:36:38PM +0100, Morten Rasmussen wrote:
> 
> And this is exactly you get with this patch :-) load_above_capacity
> (through max_pull) is multiplied by the group capacity to compute that
> actual amount of [load] to remove:
> 
> env->imbalance= load_above_capacity * busiest->group_capacity /
>   SCHED_CAPACITY_SCALE
> 
>   = 1*NICE_0_LOAD * 3*SCHED_CAPACITY_SCALE /
>   SCHED_CAPACITY_SCALE
> 
>   = 3*NICE_0_LOAD
> 
> I don't think we disagree on how it should work :-) Without the capacity
> scaling in this patch you get: 
> 
> env->imbalance = (6*SCHED_CAPACITY_SCALE - 3*SCHED_CAPACITY_SCALE) *
>   3*SCHED_CAPACITY_SCALE / SCHED_CAPACITY_SCALE
> 
>   = 9*SCHED_CAPACITY_SCALE
> 
> Coming back to Yuyang's question. I think it should be NICE_0_LOAD to
> ensure that the resulting imbalance has the proper unit [load].

Sorry, I'm still confused. After this patch, the unit is indeed [load], the
load same as the weight visible to the user. However, you literally compared
it with sg_lb_stats's avg_load and load_per_task, which has the unit of
load_avg, which is scaled_load_down(NICE_0_LOAD). Am I missing something?

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

[Jon Masters]

On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote:

> The only way this can be implemented is by pretending that the
> ACPI/PCI arch/arm64 implementation is generic code (that's what this
> series does), move it to /drivers (where it is in this series), and
> implement _DSD vendor specific bindings (per HID) to set-up the pci
> operations; whether this solution should go upstream, given that it
> is just a short-term solution for early platforms bugs, it is another
> story and my personal answer is no.

Just for completeness, let me also followup to this one.

We have real, shipping, systems in the field based on ARMv8. For
example, HPE Moonshot ProLiant m400. Not everyone loves the first
generation of anything (Applied get a lot of stick, but the reality is
that someone had to go first, and whoever that was was going to learn
all of the lessons that others don't need to) but it is out there and we
need an upstream kernel solution that includes support for that.

In the server world, we (speaking as a major distro vendor here) are not
going to entertain a situation in which non-upstream patches are needed
to even boot a platform. That simply won't do. We need to separate out
the issue of getting the core in place from the quirks, but then we need
quirks that include support for all early ARMv8 platforms that are out
there today. If we can't get to a point where a Moonshot[0] cartridge
boots out of the box with an upstream kernel, let's just give up and do
something else instead :) (joke)

Jon.

[0] HPE have been *amazingly* patient with this stuff. They've reworked
the firmware when someone (cough) pointed out that the early stuff
they'd been fed was not built according to the standards (U-Boot). They
have *really good* UEFI and ACPI enabled firmware that is running
RHEL(SA) great. But that's not good enough. We don't ship a distro with
hacks. We ship a distro derived from upstream code (although we might
have to backport a lot of stuff later). There's wiggle room, but there
is not wiggle room for core platforms. On ARM, users and developers
*will* be able to take an upstream kernel and boot it on their RHEL
install. And they *will* be able to reproduce problems against upstream,
and help develop against upstream, and further the upstream first
mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL
so that's good enough for the early generation...".

-- 
Computer Architect | Sent from my Fedora powered laptop

[PATCH v3] Coccinelle: noderef: Add new rules and correct the old rule

[Vaishali Thakkar]

Add new rules to detect the cases where sizeof is used in
function calls as a argument.

Also, for the patch mode third rule should behave same as
second rule with arguments reversed. So, change that as well.

Signed-off-by: Vaishali Thakkar 
---
Changes since v2:
- Add rules for function calls. This will behave as
  more general rules and covers cases which were
  covered by the rule in previous versions of the patch
- Change subject and commit log accordingly.
Changes since v1:
- Declare i as an expression instead of identifier to
  cover more cases
---
 scripts/coccinelle/misc/noderef.cocci | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/scripts/coccinelle/misc/noderef.cocci 
b/scripts/coccinelle/misc/noderef.cocci
index 80a831c..007f0de 100644
--- a/scripts/coccinelle/misc/noderef.cocci
+++ b/scripts/coccinelle/misc/noderef.cocci
@@ -16,6 +16,7 @@ virtual patch
 @depends on patch@
 expression *x;
 expression f;
+expression i;
 type T;
 @@
 
@@ -30,15 +31,26 @@ f(...,(T)(x),...,sizeof(
 + *x
),...)
 |
-f(...,sizeof(x),...,(T)(
+f(...,sizeof(
+- x
++ *x
+   ),...,(T)(x),...)
+|
+f(...,(T)(x),...,i*sizeof(
 - x
 + *x
),...)
+|
+f(...,i*sizeof(
+- x
++ *x
+   ),...,(T)(x),...)
 )
 
 @r depends on !patch@
 expression *x;
 expression f;
+expression i;
 position p;
 type T;
 @@
@@ -49,6 +61,10 @@ type T;
 *f(...,(T)(x),...,sizeof@p(x),...)
 |
 *f(...,sizeof@p(x),...,(T)(x),...)
+|
+*f(...,(T)(x),...,i*sizeof@p(x),...)
+|
+*f(...,i*sizeof@p(x),...,(T)(x),...)
 )
 
 @script:python depends on org@
-- 
2.1.4

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-23 16:18:13, Rob Herring wrote:
> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> > Driver utilises syscon and nvmem consumer API's to get the
> > various register values needed and expose the SoC specific
> > properties via sysfs.
> > 
> > A sample output from Colibri Vybrid VF61 is below:
> > 
> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> > family machinepower  revision   soc_id subsystem  uevent
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> > Freescale Vybrid VF610
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> > Freescale Vybrid
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> > 0013
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> > df6472a6130f29d4
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >  drivers/soc/Kconfig|   1 +
> >  drivers/soc/fsl/Kconfig|  10 ++
> >  drivers/soc/fsl/Makefile   |   1 +
> >  drivers/soc/fsl/soc-vf610.c| 198 
> > +
> >  5 files changed, 230 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >  create mode 100644 drivers/soc/fsl/Kconfig
> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..338905d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,20 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "fsl,vf610-soc"
> > +- rom-revision: phandle to the on-chip ROM node
> > +- mscm: phandle to the MSCM CPU configuration node
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> I still have similar concerns as the discussion on the last version. 
> This version only proves that you aren't describing h/w, but rather just 
> a collection of data that some driver wants.
> 
> A driver can just as easily look-up all the nodes directly that these 
> phandles point to.

Agreed, that we can look up all the nodes directly that these phandles
refer to but I would still need a DT entry to bind to. While I could
bind to existing nodes like mscm cpucfg but that doesn't seem right.

The very first approach that we had taken was to integrate this functionality
in mach-vf610.c code under mach-imx
http://www.spinics.net/lists/devicetree/msg80654.html

and then it was recommended to migrate this to drivers/soc where we did use
phandles or direct look up via compatible strings

http://www.spinics.net/lists/arm-kernel/msg420847.html

and

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html

There hasn't been a consensus since v1.

> 
> And as long as we have inconsistent use of soc_device, I don't want to 
> see any compatible strings related to it.
> 

Regards,
Sanchayan.

Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity

[Yuyang Du]

On Thu, May 19, 2016 at 04:36:38PM +0100, Morten Rasmussen wrote:
> 
> And this is exactly you get with this patch :-) load_above_capacity
> (through max_pull) is multiplied by the group capacity to compute that
> actual amount of [load] to remove:
> 
> env->imbalance= load_above_capacity * busiest->group_capacity /
>   SCHED_CAPACITY_SCALE
> 
>   = 1*NICE_0_LOAD * 3*SCHED_CAPACITY_SCALE /
>   SCHED_CAPACITY_SCALE
> 
>   = 3*NICE_0_LOAD
> 
> I don't think we disagree on how it should work :-) Without the capacity
> scaling in this patch you get: 
> 
> env->imbalance = (6*SCHED_CAPACITY_SCALE - 3*SCHED_CAPACITY_SCALE) *
>   3*SCHED_CAPACITY_SCALE / SCHED_CAPACITY_SCALE
> 
>   = 9*SCHED_CAPACITY_SCALE
> 
> Coming back to Yuyang's question. I think it should be NICE_0_LOAD to
> ensure that the resulting imbalance has the proper unit [load].

Sorry, I'm still confused. After this patch, the unit is indeed [load], the
load same as the weight visible to the user. However, you literally compared
it with sg_lb_stats's avg_load and load_per_task, which has the unit of
load_avg, which is scaled_load_down(NICE_0_LOAD). Am I missing something?

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

[Jon Masters]

On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote:

> The only way this can be implemented is by pretending that the
> ACPI/PCI arch/arm64 implementation is generic code (that's what this
> series does), move it to /drivers (where it is in this series), and
> implement _DSD vendor specific bindings (per HID) to set-up the pci
> operations; whether this solution should go upstream, given that it
> is just a short-term solution for early platforms bugs, it is another
> story and my personal answer is no.

Just for completeness, let me also followup to this one.

We have real, shipping, systems in the field based on ARMv8. For
example, HPE Moonshot ProLiant m400. Not everyone loves the first
generation of anything (Applied get a lot of stick, but the reality is
that someone had to go first, and whoever that was was going to learn
all of the lessons that others don't need to) but it is out there and we
need an upstream kernel solution that includes support for that.

In the server world, we (speaking as a major distro vendor here) are not
going to entertain a situation in which non-upstream patches are needed
to even boot a platform. That simply won't do. We need to separate out
the issue of getting the core in place from the quirks, but then we need
quirks that include support for all early ARMv8 platforms that are out
there today. If we can't get to a point where a Moonshot[0] cartridge
boots out of the box with an upstream kernel, let's just give up and do
something else instead :) (joke)

Jon.

[0] HPE have been *amazingly* patient with this stuff. They've reworked
the firmware when someone (cough) pointed out that the early stuff
they'd been fed was not built according to the standards (U-Boot). They
have *really good* UEFI and ACPI enabled firmware that is running
RHEL(SA) great. But that's not good enough. We don't ship a distro with
hacks. We ship a distro derived from upstream code (although we might
have to backport a lot of stuff later). There's wiggle room, but there
is not wiggle room for core platforms. On ARM, users and developers
*will* be able to take an upstream kernel and boot it on their RHEL
install. And they *will* be able to reproduce problems against upstream,
and help develop against upstream, and further the upstream first
mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL
so that's good enough for the early generation...".

-- 
Computer Architect | Sent from my Fedora powered laptop

[PATCH v3] Coccinelle: noderef: Add new rules and correct the old rule

[Vaishali Thakkar]

Add new rules to detect the cases where sizeof is used in
function calls as a argument.

Also, for the patch mode third rule should behave same as
second rule with arguments reversed. So, change that as well.

Signed-off-by: Vaishali Thakkar 
---
Changes since v2:
- Add rules for function calls. This will behave as
  more general rules and covers cases which were
  covered by the rule in previous versions of the patch
- Change subject and commit log accordingly.
Changes since v1:
- Declare i as an expression instead of identifier to
  cover more cases
---
 scripts/coccinelle/misc/noderef.cocci | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/scripts/coccinelle/misc/noderef.cocci 
b/scripts/coccinelle/misc/noderef.cocci
index 80a831c..007f0de 100644
--- a/scripts/coccinelle/misc/noderef.cocci
+++ b/scripts/coccinelle/misc/noderef.cocci
@@ -16,6 +16,7 @@ virtual patch
 @depends on patch@
 expression *x;
 expression f;
+expression i;
 type T;
 @@
 
@@ -30,15 +31,26 @@ f(...,(T)(x),...,sizeof(
 + *x
),...)
 |
-f(...,sizeof(x),...,(T)(
+f(...,sizeof(
+- x
++ *x
+   ),...,(T)(x),...)
+|
+f(...,(T)(x),...,i*sizeof(
 - x
 + *x
),...)
+|
+f(...,i*sizeof(
+- x
++ *x
+   ),...,(T)(x),...)
 )
 
 @r depends on !patch@
 expression *x;
 expression f;
+expression i;
 position p;
 type T;
 @@
@@ -49,6 +61,10 @@ type T;
 *f(...,(T)(x),...,sizeof@p(x),...)
 |
 *f(...,sizeof@p(x),...,(T)(x),...)
+|
+*f(...,(T)(x),...,i*sizeof@p(x),...)
+|
+*f(...,i*sizeof@p(x),...,(T)(x),...)
 )
 
 @script:python depends on org@
-- 
2.1.4

Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform

[maitysanchayan]

Hello Rob,

On 16-05-23 16:18:13, Rob Herring wrote:
> On Fri, May 20, 2016 at 03:32:05PM +0530, Sanchayan Maity wrote:
> > This adds a SoC driver to be used by Freescale Vybrid SoC's.
> > Driver utilises syscon and nvmem consumer API's to get the
> > various register values needed and expose the SoC specific
> > properties via sysfs.
> > 
> > A sample output from Colibri Vybrid VF61 is below:
> > 
> > root@colibri-vf:~# cd /sys/bus/soc/devices/soc0
> > root@colibri-vf:/sys/bus/soc/devices/soc0# ls
> > family machinepower  revision   soc_id subsystem  uevent
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat family
> > Freescale Vybrid VF610
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat machine
> > Freescale Vybrid
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat revision
> > 0013
> > root@colibri-vf:/sys/bus/soc/devices/soc0# cat soc_id
> > df6472a6130f29d4
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  .../bindings/arm/freescale/fsl,vf610-soc.txt   |  20 +++
> >  drivers/soc/Kconfig|   1 +
> >  drivers/soc/fsl/Kconfig|  10 ++
> >  drivers/soc/fsl/Makefile   |   1 +
> >  drivers/soc/fsl/soc-vf610.c| 198 
> > +
> >  5 files changed, 230 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> >  create mode 100644 drivers/soc/fsl/Kconfig
> >  create mode 100644 drivers/soc/fsl/soc-vf610.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt 
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > new file mode 100644
> > index 000..338905d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-soc.txt
> > @@ -0,0 +1,20 @@
> > +Vybrid System-on-Chip
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "fsl,vf610-soc"
> > +- rom-revision: phandle to the on-chip ROM node
> > +- mscm: phandle to the MSCM CPU configuration node
> > +- nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> > +- nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> I still have similar concerns as the discussion on the last version. 
> This version only proves that you aren't describing h/w, but rather just 
> a collection of data that some driver wants.
> 
> A driver can just as easily look-up all the nodes directly that these 
> phandles point to.

Agreed, that we can look up all the nodes directly that these phandles
refer to but I would still need a DT entry to bind to. While I could
bind to existing nodes like mscm cpucfg but that doesn't seem right.

The very first approach that we had taken was to integrate this functionality
in mach-vf610.c code under mach-imx
http://www.spinics.net/lists/devicetree/msg80654.html

and then it was recommended to migrate this to drivers/soc where we did use
phandles or direct look up via compatible strings

http://www.spinics.net/lists/arm-kernel/msg420847.html

and

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html

There hasn't been a consensus since v1.

> 
> And as long as we have inconsistent use of soc_device, I don't want to 
> see any compatible strings related to it.
> 

Regards,
Sanchayan.

Re: [PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

[David Miller]

From: 严海双 
Date: Tue, 24 May 2016 11:55:31 +0800

> 
>> On May 24, 2016, at 11:14 AM, Eric Dumazet  wrote:
>> 
>> On Tue, 2016-05-24 at 10:39 +0800, Haishuang Yan wrote:
>>> For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6).
>>> 
>>> ---
>>> Changes in v2:
>>>  - Place the "#if IS_ENABLED" block before the "} else if
>>> (..) {" piece and the "#endif" before the closing brace and this
>>> becomes much easier to look at.
>> 
>> _Why_ is this patch needed ?
>> 
>> Please describe in the changelog what _actual_ problem you are trying to
>> address.
>> 
>> We have many points in the kernel using ipv6_get_dsfield() even if
>> CONFIG_IPV6=n, and it seems fine to me at least.
>> 
>> Thanks.
>> 
>> 
>> 
> 
> Yes, you’re right, but I think add this patch seems more reasonable in coding.

No, it isn't more reasonable at all.

We have the backup implementations when CONFIG_IPV6 is disabled
_EXACTLY_ to avoid ifdef crap like this in C files.

Re: [PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

[David Miller]

From: 严海双 
Date: Tue, 24 May 2016 11:55:31 +0800

> 
>> On May 24, 2016, at 11:14 AM, Eric Dumazet  wrote:
>> 
>> On Tue, 2016-05-24 at 10:39 +0800, Haishuang Yan wrote:
>>> For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6).
>>> 
>>> ---
>>> Changes in v2:
>>>  - Place the "#if IS_ENABLED" block before the "} else if
>>> (..) {" piece and the "#endif" before the closing brace and this
>>> becomes much easier to look at.
>> 
>> _Why_ is this patch needed ?
>> 
>> Please describe in the changelog what _actual_ problem you are trying to
>> address.
>> 
>> We have many points in the kernel using ipv6_get_dsfield() even if
>> CONFIG_IPV6=n, and it seems fine to me at least.
>> 
>> Thanks.
>> 
>> 
>> 
> 
> Yes, you’re right, but I think add this patch seems more reasonable in coding.

No, it isn't more reasonable at all.

We have the backup implementations when CONFIG_IPV6 is disabled
_EXACTLY_ to avoid ifdef crap like this in C files.

Re: crosstool builds - https://www.kernel.org/pub/tools/crosstool/

[Tony Breeds]

On Thu, May 19, 2016 at 11:48:39PM -0400, Jon Masters wrote:
> Hi Tony,
> 
> I'm wondering whether you know of anyone who has picked up where you
> left off, building cross toolchains for various and sundry alternative
> architectures? I wanted to download an IA64 compiler recently (really)
> and noticed that the most recent builds were against GCC 4.6.3.

Chris (on CC) is a co-worker (ish, it's complicated) that I've been nagging to
take over where I left off.

I'm sure there is a process for getting Chris access to the korg infrastructure
but in the mean time I'm *sure* he can fond somewhere to build them.

All my patches and scripts are public so go nuts :)

> Thanks in advance, and for making these before!

No problem it was fun, but (as happens in our community) I've changed focus and
can't make the time for them.

Yours Tony.


signature.asc
Description: PGP signature

Re: crosstool builds - https://www.kernel.org/pub/tools/crosstool/

[Tony Breeds]

On Thu, May 19, 2016 at 11:48:39PM -0400, Jon Masters wrote:
> Hi Tony,
> 
> I'm wondering whether you know of anyone who has picked up where you
> left off, building cross toolchains for various and sundry alternative
> architectures? I wanted to download an IA64 compiler recently (really)
> and noticed that the most recent builds were against GCC 4.6.3.

Chris (on CC) is a co-worker (ish, it's complicated) that I've been nagging to
take over where I left off.

I'm sure there is a process for getting Chris access to the korg infrastructure
but in the mean time I'm *sure* he can fond somewhere to build them.

All my patches and scripts are public so go nuts :)

> Thanks in advance, and for making these before!

No problem it was fun, but (as happens in our community) I've changed focus and
can't make the time for them.

Yours Tony.


signature.asc
Description: PGP signature

Re: [PATCH 3/3] ARM: configs: keystone: Enable PINCTRL_SINGLE Config

[Keerthy]

On Tuesday 24 May 2016 09:07 AM, Lokesh Vutla wrote:



On Monday 23 May 2016 05:59 PM, Keerthy wrote:

keystone-k2l devices use pinmux and are compliant with PINCTRL_SINGLE.
Hence enable the config option.

Signed-off-by: Keerthy 


A similar patch[1] is already posted.

[1]https://patchwork.kernel.org/patch/8958091/


Ah I had not seen them. If they are already reviewed and closer to be 
merged then Patch 2 and Patch 3 of this series can be dropped.


Regards,
Keerthy



Thanks and regards,
Lokesh


---
  arch/arm/configs/keystone_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index faba04d..71b42e6 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -144,6 +144,7 @@ CONFIG_I2C_DAVINCI=y
  CONFIG_SPI=y
  CONFIG_SPI_DAVINCI=y
  CONFIG_SPI_SPIDEV=y
+CONFIG_PINCTRL_SINGLE=y
  CONFIG_GPIOLIB=y
  CONFIG_GPIO_SYSFS=y
  CONFIG_GPIO_DAVINCI=y

Re: [PATCH 3/3] ARM: configs: keystone: Enable PINCTRL_SINGLE Config

[Keerthy]

On Tuesday 24 May 2016 09:07 AM, Lokesh Vutla wrote:



On Monday 23 May 2016 05:59 PM, Keerthy wrote:

keystone-k2l devices use pinmux and are compliant with PINCTRL_SINGLE.
Hence enable the config option.

Signed-off-by: Keerthy 


A similar patch[1] is already posted.

[1]https://patchwork.kernel.org/patch/8958091/


Ah I had not seen them. If they are already reviewed and closer to be 
merged then Patch 2 and Patch 3 of this series can be dropped.


Regards,
Keerthy



Thanks and regards,
Lokesh


---
  arch/arm/configs/keystone_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index faba04d..71b42e6 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -144,6 +144,7 @@ CONFIG_I2C_DAVINCI=y
  CONFIG_SPI=y
  CONFIG_SPI_DAVINCI=y
  CONFIG_SPI_SPIDEV=y
+CONFIG_PINCTRL_SINGLE=y
  CONFIG_GPIOLIB=y
  CONFIG_GPIO_SYSFS=y
  CONFIG_GPIO_DAVINCI=y

Re: [PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

[严海双]

> On May 24, 2016, at 11:14 AM, Eric Dumazet  wrote:
> 
> On Tue, 2016-05-24 at 10:39 +0800, Haishuang Yan wrote:
>> For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6).
>> 
>> ---
>> Changes in v2:
>>  - Place the "#if IS_ENABLED" block before the "} else if
>> (..) {" piece and the "#endif" before the closing brace and this
>> becomes much easier to look at.
> 
> _Why_ is this patch needed ?
> 
> Please describe in the changelog what _actual_ problem you are trying to
> address.
> 
> We have many points in the kernel using ipv6_get_dsfield() even if
> CONFIG_IPV6=n, and it seems fine to me at least.
> 
> Thanks.
> 
> 
> 

Yes, you’re right, but I think add this patch seems more reasonable in coding.

Thanks for your reviewing.

Re: [PATCH v2] ip_tunnel: enclose a code block in macro IS_ENABLED(CONFIG_IPV6)

[严海双]

> On May 24, 2016, at 11:14 AM, Eric Dumazet  wrote:
> 
> On Tue, 2016-05-24 at 10:39 +0800, Haishuang Yan wrote:
>> For ipv6 case, enclose the code block in macro IS_ENABLED(CONFIG_IPV6).
>> 
>> ---
>> Changes in v2:
>>  - Place the "#if IS_ENABLED" block before the "} else if
>> (..) {" piece and the "#endif" before the closing brace and this
>> becomes much easier to look at.
> 
> _Why_ is this patch needed ?
> 
> Please describe in the changelog what _actual_ problem you are trying to
> address.
> 
> We have many points in the kernel using ipv6_get_dsfield() even if
> CONFIG_IPV6=n, and it seems fine to me at least.
> 
> Thanks.
> 
> 
> 

Yes, you’re right, but I think add this patch seems more reasonable in coding.

Thanks for your reviewing.

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

[Andy Lutomirski]

On May 23, 2016 7:28 PM, "Josh Poimboeuf"  wrote:
> > Maybe I'm coming around to liking this idea.
>
> Ok, good :-)
>
> > In an ideal world (DWARF support, high-quality unwinder, nice pretty
> > printer, etc), unwinding across a kernel exception would look like:
> >
> >  - some_func
> >  - some_other_func
> >  - do_page_fault
> >  - page_fault
> >
> > After page_fault, the next unwind step takes us to the faulting RIP
> > (faulting_func) and reports that all GPRs are known.  It should
> > probably learn this fact from DWARF if DWARF is available, instead of
> > directly decoding pt_regs, due to a few funny cases in which pt_regs
> > may be incomplete.  A nice pretty printer could now print all the
> > regs.
> >
> >  - faulting_func
> >  - etc.
> >
> > For this to work, we don't actually need the unwinder to explicitly
> > know where pt_regs is.
>
> That's true (but only for DWARF).
>
> > Food for thought, though: if user code does SYSENTER with TF set,
> > you'll end up with partial pt_regs.  There's nothing the kernel can do
> > about it.  DWARF will handle it without any fanfare, but I don't know
> > if it's going to cause trouble for you pre-DWARF.
>
> In this case it should see the stack pointer is past the pt_regs offset,
> so it would just report it as an empty stack.

OK

>
> > I'm also not sure it makes sense to apply this before the unwinder
> > that can consume it is ready.  Maybe, if it would be consistent with
> > your plans, it would make sense to rewrite the unwinder first, then
> > apply this and teach live patching to use the new unwinder, and *then*
> > add DWARF support?
>
> For the purposes of livepatch, the reliable unwinder needs to detect
> whether an interrupt/exception pt_regs frame exists on a sleeping task
> (or current).  This patch would allow us to do that.
>
> So my preferred order of doing things would be:
>
> 1) Brian Gerst's switch_to() cleanup and any related unwinder fixes
> 2) this patch for annotating pt_regs stack frames
> 3) reliable unwinder, similar to what I already posted, except it relies
>on this patch instead of PF_PREEMPT_IRQ, and knows how to deal with
>the new inactive task frame format of #1
> 4) livepatch consistency model which uses the reliable unwinder
> 5) rewrite unwinder, and port all users to the new interface
> 6) add DWARF unwinder
>
> 1-4 are pretty much already written, whereas 5 and 6 will take
> considerably more work.

Fair enough.

>
> > > +   /*
> > > +* Create a stack frame for the saved pt_regs.  This allows frame
> > > +* pointer based unwinders to find pt_regs on the stack.
> > > +*/
> > > +   .macro CREATE_PT_REGS_FRAME regs=%rsp
> > > +#ifdef CONFIG_FRAME_POINTER
> > > +   pushq   \regs
> > > +   pushq   $pt_regs+1
> >
> > Why the +1?
>
> Some unwinders like gdb are smart enough to report the function which
> contains the instruction *before* the return address.  Without the +1,
> they would show the wrong function.

Lovely.  Want to add a comment?

>
> > > +   pushq   %rbp
> > > +   movq%rsp, %rbp
> > > +#endif
> > > +   .endm
> >
> > I keep wanting this to be only two pushes and to fudge rbp to make it
> > work, but I don't see a good way.  But let's call it
> > CREATE_NESTED_ENTRY_FRAME or something, and let's rename pt_regs to
> > nested_frame or similar.
>
> Or, if we aren't going to annotate syscall pt_regs, we could give it a
> more specific name.  CREATE_INTERRUPT_FRAME and interrupt_frame()?

CREATE_INTERRUPT_FRAME is confusing because it applies to idtentry,
too.  CREATE_PT_REGS_FRAME is probably fine.

> > > +
> > > +/* fake function which allows stack unwinders to detect pt_regs frames */
> > > +#ifdef CONFIG_FRAME_POINTER
> > > +ENTRY(pt_regs)
> > > +   nop
> > > +   nop
> > > +ENDPROC(pt_regs)
> > > +#endif /* CONFIG_FRAME_POINTER */
> >
> > Why is this two bytes long?  Is there some reason it has to be more
> > than one byte?
>
> Similar to above, this is related to the need to support various
> unwinders.  Whether the unwinder displays the ret_addr or the
> instruction preceding it, either way the instruction needs to be inside
> the function for the function to be reported.

OK.

--Andy

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

[Andy Lutomirski]

On May 23, 2016 7:28 PM, "Josh Poimboeuf"  wrote:
> > Maybe I'm coming around to liking this idea.
>
> Ok, good :-)
>
> > In an ideal world (DWARF support, high-quality unwinder, nice pretty
> > printer, etc), unwinding across a kernel exception would look like:
> >
> >  - some_func
> >  - some_other_func
> >  - do_page_fault
> >  - page_fault
> >
> > After page_fault, the next unwind step takes us to the faulting RIP
> > (faulting_func) and reports that all GPRs are known.  It should
> > probably learn this fact from DWARF if DWARF is available, instead of
> > directly decoding pt_regs, due to a few funny cases in which pt_regs
> > may be incomplete.  A nice pretty printer could now print all the
> > regs.
> >
> >  - faulting_func
> >  - etc.
> >
> > For this to work, we don't actually need the unwinder to explicitly
> > know where pt_regs is.
>
> That's true (but only for DWARF).
>
> > Food for thought, though: if user code does SYSENTER with TF set,
> > you'll end up with partial pt_regs.  There's nothing the kernel can do
> > about it.  DWARF will handle it without any fanfare, but I don't know
> > if it's going to cause trouble for you pre-DWARF.
>
> In this case it should see the stack pointer is past the pt_regs offset,
> so it would just report it as an empty stack.

OK

>
> > I'm also not sure it makes sense to apply this before the unwinder
> > that can consume it is ready.  Maybe, if it would be consistent with
> > your plans, it would make sense to rewrite the unwinder first, then
> > apply this and teach live patching to use the new unwinder, and *then*
> > add DWARF support?
>
> For the purposes of livepatch, the reliable unwinder needs to detect
> whether an interrupt/exception pt_regs frame exists on a sleeping task
> (or current).  This patch would allow us to do that.
>
> So my preferred order of doing things would be:
>
> 1) Brian Gerst's switch_to() cleanup and any related unwinder fixes
> 2) this patch for annotating pt_regs stack frames
> 3) reliable unwinder, similar to what I already posted, except it relies
>on this patch instead of PF_PREEMPT_IRQ, and knows how to deal with
>the new inactive task frame format of #1
> 4) livepatch consistency model which uses the reliable unwinder
> 5) rewrite unwinder, and port all users to the new interface
> 6) add DWARF unwinder
>
> 1-4 are pretty much already written, whereas 5 and 6 will take
> considerably more work.

Fair enough.

>
> > > +   /*
> > > +* Create a stack frame for the saved pt_regs.  This allows frame
> > > +* pointer based unwinders to find pt_regs on the stack.
> > > +*/
> > > +   .macro CREATE_PT_REGS_FRAME regs=%rsp
> > > +#ifdef CONFIG_FRAME_POINTER
> > > +   pushq   \regs
> > > +   pushq   $pt_regs+1
> >
> > Why the +1?
>
> Some unwinders like gdb are smart enough to report the function which
> contains the instruction *before* the return address.  Without the +1,
> they would show the wrong function.

Lovely.  Want to add a comment?

>
> > > +   pushq   %rbp
> > > +   movq%rsp, %rbp
> > > +#endif
> > > +   .endm
> >
> > I keep wanting this to be only two pushes and to fudge rbp to make it
> > work, but I don't see a good way.  But let's call it
> > CREATE_NESTED_ENTRY_FRAME or something, and let's rename pt_regs to
> > nested_frame or similar.
>
> Or, if we aren't going to annotate syscall pt_regs, we could give it a
> more specific name.  CREATE_INTERRUPT_FRAME and interrupt_frame()?

CREATE_INTERRUPT_FRAME is confusing because it applies to idtentry,
too.  CREATE_PT_REGS_FRAME is probably fine.

> > > +
> > > +/* fake function which allows stack unwinders to detect pt_regs frames */
> > > +#ifdef CONFIG_FRAME_POINTER
> > > +ENTRY(pt_regs)
> > > +   nop
> > > +   nop
> > > +ENDPROC(pt_regs)
> > > +#endif /* CONFIG_FRAME_POINTER */
> >
> > Why is this two bytes long?  Is there some reason it has to be more
> > than one byte?
>
> Similar to above, this is related to the need to support various
> unwinders.  Whether the unwinder displays the ret_addr or the
> instruction preceding it, either way the instruction needs to be inside
> the function for the function to be reported.

OK.

--Andy

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

[Andrei Borzenkov]

24.05.2016 02:03, Gabriele Mazzotta пишет:
> On 24/05/2016 00:22, Pali Rohár wrote:
>> On Tuesday 24 May 2016 00:17:15 Darren Hart wrote:
>>> On Tue, May 24, 2016 at 12:06:03AM +0200, Pali Rohár wrote:
 On Monday 23 May 2016 23:26:55 Darren Hart wrote:
> I've queued this. Thanks for your patience.

 Ok, In that case I would update comments in patch to try it more
 clear what code is doing.
>>>
>>> I thought I had your approval on this one Pali. Apologies if that was
>>> not the case. Did I miss a change request from you?
>>>
>>> If so, please point me at it, and I'll dequeue this one and wait for
>>> an updated one.
>>
>> I just wanted to review that code from somebody else and decide if 
>> accept it or not. Because I was not sure if it is OK...
>>
>> But there was no objection, so patch is OK.
>>
>> And I pointed that patch could have better comments to describe what it 
>> is doing as at first time I was confused.
>>
>> So I believe that you can update patch in your queue with new version 
>> which just change comments in source code (without functional changes).
>>
> 
> Something such as the following?
> Feel free to reword the comments if you have something better in mind.
> 
> ---
>  drivers/platform/x86/dell-rbtn.c | 56 
> 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-rbtn.c 
> b/drivers/platform/x86/dell-rbtn.c
> index 331d63c..e0208ba 100644
> --- a/drivers/platform/x86/dell-rbtn.c
> +++ b/drivers/platform/x86/dell-rbtn.c
> @@ -28,6 +28,7 @@ struct rbtn_data {
>   enum rbtn_type type;
>   struct rfkill *rfkill;
>   struct input_dev *input_dev;
> + bool suspended;
>  };
>  
>  
> @@ -235,9 +236,55 @@ static const struct acpi_device_id rbtn_ids[] = {
>   { "", 0 },
>  };
>  
> +#ifdef CONFIG_PM_SLEEP
> +static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context)
> +{
> + struct rbtn_data *rbtn_data = context;
> +
> + rbtn_data->suspended = false;
> +}
> +
> +static int rbtn_suspend(struct device *dev)
> +{
> + struct acpi_device *device = to_acpi_device(dev);
> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> +
> + rbtn_data->suspended = true;
> +
> + return 0;
> +}
> +
> +static int rbtn_resume(struct device *dev)
> +{
> + struct acpi_device *device = to_acpi_device(dev);
> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> + acpi_status status;
> +
> + /*
> +  * Upon resume, some BIOSes autonomously send an ACPI notification
> +  * that triggers an unwanted input event. In order to ignore it,
> +  * we use a flag that we set at suspend and clear once we have
> +  * received the extra notification. Since ACPI notifications are
> +  * delivered asynchronously to drivers, we clear the flag from the
> +  * workqueue used to deliver the notifications. This should be enough
> +  * to guarantee that the flag is cleared only after we received the
> +  * extra notification, if any.
> +  */

"guarantee" is rather strong word here. We really do not know anything
how and when these notifications are generated by firmware, so can only
hope. But otherwise this explains what this patch intends to do (so that
even me finally understood it :)

> + status = acpi_os_execute(OSL_NOTIFY_HANDLER,
> +  rbtn_acpi_clear_flag, rbtn_data);
> + if (ACPI_FAILURE(status))
> + rbtn_data->suspended = false;
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(rbtn_pm_ops, rbtn_suspend, rbtn_resume);
> +
>  static struct acpi_driver rbtn_driver = {
>   .name = "dell-rbtn",
>   .ids = rbtn_ids,
> + .drv.pm = _pm_ops,
>   .ops = {
>   .add = rbtn_add,
>   .remove = rbtn_remove,
> @@ -399,6 +446,15 @@ static void rbtn_notify(struct acpi_device *device, u32 
> event)
>  {
>   struct rbtn_data *rbtn_data = device->driver_data;
>  
> + /*
> +  * Some BIOSes send autonomously a notification at resume.
> +  * Ignore it to prevent unwanted input events.
> +  */
> + if (rbtn_data->suspended) {
> + dev_dbg(>dev, "ACPI notification ignored\n");
> + return;
> + }
> +
>   if (event != 0x80) {
>   dev_info(>dev, "Received unknown event (0x%x)\n",
>event);
> 

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

[Andrei Borzenkov]

24.05.2016 02:03, Gabriele Mazzotta пишет:
> On 24/05/2016 00:22, Pali Rohár wrote:
>> On Tuesday 24 May 2016 00:17:15 Darren Hart wrote:
>>> On Tue, May 24, 2016 at 12:06:03AM +0200, Pali Rohár wrote:
 On Monday 23 May 2016 23:26:55 Darren Hart wrote:
> I've queued this. Thanks for your patience.

 Ok, In that case I would update comments in patch to try it more
 clear what code is doing.
>>>
>>> I thought I had your approval on this one Pali. Apologies if that was
>>> not the case. Did I miss a change request from you?
>>>
>>> If so, please point me at it, and I'll dequeue this one and wait for
>>> an updated one.
>>
>> I just wanted to review that code from somebody else and decide if 
>> accept it or not. Because I was not sure if it is OK...
>>
>> But there was no objection, so patch is OK.
>>
>> And I pointed that patch could have better comments to describe what it 
>> is doing as at first time I was confused.
>>
>> So I believe that you can update patch in your queue with new version 
>> which just change comments in source code (without functional changes).
>>
> 
> Something such as the following?
> Feel free to reword the comments if you have something better in mind.
> 
> ---
>  drivers/platform/x86/dell-rbtn.c | 56 
> 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-rbtn.c 
> b/drivers/platform/x86/dell-rbtn.c
> index 331d63c..e0208ba 100644
> --- a/drivers/platform/x86/dell-rbtn.c
> +++ b/drivers/platform/x86/dell-rbtn.c
> @@ -28,6 +28,7 @@ struct rbtn_data {
>   enum rbtn_type type;
>   struct rfkill *rfkill;
>   struct input_dev *input_dev;
> + bool suspended;
>  };
>  
>  
> @@ -235,9 +236,55 @@ static const struct acpi_device_id rbtn_ids[] = {
>   { "", 0 },
>  };
>  
> +#ifdef CONFIG_PM_SLEEP
> +static void ACPI_SYSTEM_XFACE rbtn_acpi_clear_flag(void *context)
> +{
> + struct rbtn_data *rbtn_data = context;
> +
> + rbtn_data->suspended = false;
> +}
> +
> +static int rbtn_suspend(struct device *dev)
> +{
> + struct acpi_device *device = to_acpi_device(dev);
> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> +
> + rbtn_data->suspended = true;
> +
> + return 0;
> +}
> +
> +static int rbtn_resume(struct device *dev)
> +{
> + struct acpi_device *device = to_acpi_device(dev);
> + struct rbtn_data *rbtn_data = acpi_driver_data(device);
> + acpi_status status;
> +
> + /*
> +  * Upon resume, some BIOSes autonomously send an ACPI notification
> +  * that triggers an unwanted input event. In order to ignore it,
> +  * we use a flag that we set at suspend and clear once we have
> +  * received the extra notification. Since ACPI notifications are
> +  * delivered asynchronously to drivers, we clear the flag from the
> +  * workqueue used to deliver the notifications. This should be enough
> +  * to guarantee that the flag is cleared only after we received the
> +  * extra notification, if any.
> +  */

"guarantee" is rather strong word here. We really do not know anything
how and when these notifications are generated by firmware, so can only
hope. But otherwise this explains what this patch intends to do (so that
even me finally understood it :)

> + status = acpi_os_execute(OSL_NOTIFY_HANDLER,
> +  rbtn_acpi_clear_flag, rbtn_data);
> + if (ACPI_FAILURE(status))
> + rbtn_data->suspended = false;
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(rbtn_pm_ops, rbtn_suspend, rbtn_resume);
> +
>  static struct acpi_driver rbtn_driver = {
>   .name = "dell-rbtn",
>   .ids = rbtn_ids,
> + .drv.pm = _pm_ops,
>   .ops = {
>   .add = rbtn_add,
>   .remove = rbtn_remove,
> @@ -399,6 +446,15 @@ static void rbtn_notify(struct acpi_device *device, u32 
> event)
>  {
>   struct rbtn_data *rbtn_data = device->driver_data;
>  
> + /*
> +  * Some BIOSes send autonomously a notification at resume.
> +  * Ignore it to prevent unwanted input events.
> +  */
> + if (rbtn_data->suspended) {
> + dev_dbg(>dev, "ACPI notification ignored\n");
> + return;
> + }
> +
>   if (event != 0x80) {
>   dev_info(>dev, "Received unknown event (0x%x)\n",
>event);
> 

[PATCH] ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY

[Xing Zheng]

From: Sugar Zhang 

this patch make it more reasonable and readable, because when we chose
I2S_CKR_TRCM_TXONLY, we only output clk_lrck_tx, and hardware need to
confirm this signal is wired to external codec lrck_tx/rx at the same time.

for convenience, we just handle lrck_txonly if we enable symmetric_rates
in driver and dai_link. otherwise, we use the separate lrck_tx/rx.

Signed-off-by: Sugar Zhang 
Signed-off-by: Xing Zheng 
---

 sound/soc/rockchip/rockchip_i2s.c |4 ++--
 sound/soc/rockchip/rockchip_i2s.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index 574c6af..92a405f 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -306,8 +306,8 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream 
*substream,
   I2S_DMACR_RDL(16));
 
val = I2S_CKR_TRCM_TXRX;
-   if (dai->driver->symmetric_rates || rtd->dai_link->symmetric_rates)
-   val = I2S_CKR_TRCM_TXSHARE;
+   if (dai->driver->symmetric_rates && rtd->dai_link->symmetric_rates)
+   val = I2S_CKR_TRCM_TXONLY;
 
regmap_update_bits(i2s->regmap, I2S_CKR,
   I2S_CKR_TRCM_MASK,
diff --git a/sound/soc/rockchip/rockchip_i2s.h 
b/sound/soc/rockchip/rockchip_i2s.h
index dc6e2c7..13b1d44 100644
--- a/sound/soc/rockchip/rockchip_i2s.h
+++ b/sound/soc/rockchip/rockchip_i2s.h
@@ -81,8 +81,8 @@
 #define I2S_CKR_TRCM_SHIFT 28
 #define I2S_CKR_TRCM(x)(x << I2S_CKR_TRCM_SHIFT)
 #define I2S_CKR_TRCM_TXRX  (0 << I2S_CKR_TRCM_SHIFT)
-#define I2S_CKR_TRCM_TXSHARE   (1 << I2S_CKR_TRCM_SHIFT)
-#define I2S_CKR_TRCM_RXSHARE   (2 << I2S_CKR_TRCM_SHIFT)
+#define I2S_CKR_TRCM_TXONLY(1 << I2S_CKR_TRCM_SHIFT)
+#define I2S_CKR_TRCM_RXONLY(2 << I2S_CKR_TRCM_SHIFT)
 #define I2S_CKR_TRCM_MASK  (3 << I2S_CKR_TRCM_SHIFT)
 #define I2S_CKR_MSS_SHIFT  27
 #define I2S_CKR_MSS_MASTER (0 << I2S_CKR_MSS_SHIFT)
-- 
1.7.9.5

[PATCH] ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY

[Xing Zheng]

From: Sugar Zhang 

this patch make it more reasonable and readable, because when we chose
I2S_CKR_TRCM_TXONLY, we only output clk_lrck_tx, and hardware need to
confirm this signal is wired to external codec lrck_tx/rx at the same time.

for convenience, we just handle lrck_txonly if we enable symmetric_rates
in driver and dai_link. otherwise, we use the separate lrck_tx/rx.

Signed-off-by: Sugar Zhang 
Signed-off-by: Xing Zheng 
---

 sound/soc/rockchip/rockchip_i2s.c |4 ++--
 sound/soc/rockchip/rockchip_i2s.h |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index 574c6af..92a405f 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -306,8 +306,8 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream 
*substream,
   I2S_DMACR_RDL(16));
 
val = I2S_CKR_TRCM_TXRX;
-   if (dai->driver->symmetric_rates || rtd->dai_link->symmetric_rates)
-   val = I2S_CKR_TRCM_TXSHARE;
+   if (dai->driver->symmetric_rates && rtd->dai_link->symmetric_rates)
+   val = I2S_CKR_TRCM_TXONLY;
 
regmap_update_bits(i2s->regmap, I2S_CKR,
   I2S_CKR_TRCM_MASK,
diff --git a/sound/soc/rockchip/rockchip_i2s.h 
b/sound/soc/rockchip/rockchip_i2s.h
index dc6e2c7..13b1d44 100644
--- a/sound/soc/rockchip/rockchip_i2s.h
+++ b/sound/soc/rockchip/rockchip_i2s.h
@@ -81,8 +81,8 @@
 #define I2S_CKR_TRCM_SHIFT 28
 #define I2S_CKR_TRCM(x)(x << I2S_CKR_TRCM_SHIFT)
 #define I2S_CKR_TRCM_TXRX  (0 << I2S_CKR_TRCM_SHIFT)
-#define I2S_CKR_TRCM_TXSHARE   (1 << I2S_CKR_TRCM_SHIFT)
-#define I2S_CKR_TRCM_RXSHARE   (2 << I2S_CKR_TRCM_SHIFT)
+#define I2S_CKR_TRCM_TXONLY(1 << I2S_CKR_TRCM_SHIFT)
+#define I2S_CKR_TRCM_RXONLY(2 << I2S_CKR_TRCM_SHIFT)
 #define I2S_CKR_TRCM_MASK  (3 << I2S_CKR_TRCM_SHIFT)
 #define I2S_CKR_MSS_SHIFT  27
 #define I2S_CKR_MSS_MASTER (0 << I2S_CKR_MSS_SHIFT)
-- 
1.7.9.5