Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Minchan Kim]

On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim  wrote:
> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> >>  wrote:
> >> > Hello,
> >> >
> >> > On (08/22/16 16:25), Hui Zhu wrote:
> >> >>
> >> >> Current ZRAM just can store all pages even if the compression rate
> >> >> of a page is really low.  So the compression rate of ZRAM is out of
> >> >> control when it is running.
> >> >> In my part, I did some test and record with ZRAM.  The compression rate
> >> >> is about 40%.
> >> >>
> >> >> This series of patches make ZRAM can just store the page that the
> >> >> compressed size is smaller than a value.
> >> >> With these patches, I set the value to 2048 and did the same test with
> >> >> before.  The compression rate is about 20%.  The times of 
> >> >> lowmemorykiller
> >> >> also decreased.
> >> >
> >> > I haven't looked at the patches in details yet. can you educate me a bit?
> >> > is your test stable? why the number of lowmemorykill-s has decreased?
> >> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
> >> >
> >> > suppose you have X pages that result in bad compression size (from zram
> >> > point of view). zram stores such pages uncompressed, IOW we have no 
> >> > memory
> >> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
> >> > don't try to store those pages in zsmalloc, but keep them as unevictable.
> >> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
> >> > improve LMK?
> >>
> >> No, zram will not save this page uncompressed with these patches.  It
> >> will set it as non-swap and kick back to shrink_page_list.
> >> Shrink_page_list will remove this page from swapcache and kick it to
> >> unevictable list.
> >> Then this page will not be swaped before it get write.
> >> That is why most of code are around vmscan.c.
> >
> > If I understand Sergey's point right, he means there is no gain
> > to save memory between before and after.
> >
> > With your approach, you can prevent unnecessary pageout(i.e.,
> > uncompressible page swap out) but it doesn't mean you save the
> > memory compared to old so why does your patch decrease the number of
> > lowmemory killing?
> >
> > A thing I can imagine is without this feature, zram could be full of
> > uncompressible pages so good-compressible page cannot be swapped out.
> > Hui, is this scenario right for your case?
> >
> 
> That is one reason.  But it is not the principal one.
> 
> Another reason is when swap is running to put page to zram, what the
> system wants is to get memory.
> Then the deal is system spends cpu time and memory to get memory. If
> the zram just access the high compression rate pages, system can get
> more memory with the same amount of memory. It will pull system from
> low memory status earlier. (Maybe more cpu time, because the
> compression rate checks. But maybe less, because fewer pages need to
> digress. That is the interesting part. :)
> I think that is why lmk times decrease.
> 
> And yes, all of this depends on the number of high compression rate
> pages. So you cannot just set a non_swap limit to the system and get
> everything. You need to do a lot of test around it to make sure the
> non_swap limit is good for your system.
> 
> And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
> special list will make cpu too busy sometimes.

Yes, and it would same with your patch if new arraival write on CoWed
page is uncompressible data.

> I did some tests before I kick page to a special list. The shrink task

What kinds of test? Could you elaborate a bit more?
shrink task. What does it mean?

> will be moved around, around and around because low compression rate
> pages just moved from one list to another a lot of times, again, again
> and again.
> And all this low compression rate pages always stay together.

I cannot understand with detail description. :(
Could you explain more?

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Minchan Kim]

On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim  wrote:
> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> >>  wrote:
> >> > Hello,
> >> >
> >> > On (08/22/16 16:25), Hui Zhu wrote:
> >> >>
> >> >> Current ZRAM just can store all pages even if the compression rate
> >> >> of a page is really low.  So the compression rate of ZRAM is out of
> >> >> control when it is running.
> >> >> In my part, I did some test and record with ZRAM.  The compression rate
> >> >> is about 40%.
> >> >>
> >> >> This series of patches make ZRAM can just store the page that the
> >> >> compressed size is smaller than a value.
> >> >> With these patches, I set the value to 2048 and did the same test with
> >> >> before.  The compression rate is about 20%.  The times of 
> >> >> lowmemorykiller
> >> >> also decreased.
> >> >
> >> > I haven't looked at the patches in details yet. can you educate me a bit?
> >> > is your test stable? why the number of lowmemorykill-s has decreased?
> >> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
> >> >
> >> > suppose you have X pages that result in bad compression size (from zram
> >> > point of view). zram stores such pages uncompressed, IOW we have no 
> >> > memory
> >> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
> >> > don't try to store those pages in zsmalloc, but keep them as unevictable.
> >> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
> >> > improve LMK?
> >>
> >> No, zram will not save this page uncompressed with these patches.  It
> >> will set it as non-swap and kick back to shrink_page_list.
> >> Shrink_page_list will remove this page from swapcache and kick it to
> >> unevictable list.
> >> Then this page will not be swaped before it get write.
> >> That is why most of code are around vmscan.c.
> >
> > If I understand Sergey's point right, he means there is no gain
> > to save memory between before and after.
> >
> > With your approach, you can prevent unnecessary pageout(i.e.,
> > uncompressible page swap out) but it doesn't mean you save the
> > memory compared to old so why does your patch decrease the number of
> > lowmemory killing?
> >
> > A thing I can imagine is without this feature, zram could be full of
> > uncompressible pages so good-compressible page cannot be swapped out.
> > Hui, is this scenario right for your case?
> >
> 
> That is one reason.  But it is not the principal one.
> 
> Another reason is when swap is running to put page to zram, what the
> system wants is to get memory.
> Then the deal is system spends cpu time and memory to get memory. If
> the zram just access the high compression rate pages, system can get
> more memory with the same amount of memory. It will pull system from
> low memory status earlier. (Maybe more cpu time, because the
> compression rate checks. But maybe less, because fewer pages need to
> digress. That is the interesting part. :)
> I think that is why lmk times decrease.
> 
> And yes, all of this depends on the number of high compression rate
> pages. So you cannot just set a non_swap limit to the system and get
> everything. You need to do a lot of test around it to make sure the
> non_swap limit is good for your system.
> 
> And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
> special list will make cpu too busy sometimes.

Yes, and it would same with your patch if new arraival write on CoWed
page is uncompressible data.

> I did some tests before I kick page to a special list. The shrink task

What kinds of test? Could you elaborate a bit more?
shrink task. What does it mean?

> will be moved around, around and around because low compression rate
> pages just moved from one list to another a lot of times, again, again
> and again.
> And all this low compression rate pages always stay together.

I cannot understand with detail description. :(
Could you explain more?

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

[Jarkko Sakkinen]

On Sun, Sep 04, 2016 at 02:14:06PM -0600, Jason Gunthorpe wrote:
> On Sat, Sep 03, 2016 at 09:26:05AM +0300, Jarkko Sakkinen wrote:
> > > 
> > > OK, how would one get the chip instance?
> 
> Most subsystems have a get function that returns a kref'd pointer. For
> TPM all we really need today is a 'get_default_tpm_for_ns' kind of
> function.

Sorry, but I have no idea what you are talking about.

This does not imply that these structure definitions need to be in
include/linux/tpm.h since you are talking something that does not exist.

> > This still doesn't explain why moving the structures inside the driver
> > would be wrong. Even if outside callers would use a pointer the
> > structure could be opaque.
> 
> For instance, if we did a get function then the 'put' function would
> be an inline around dev_put and that needs to see inside the chip.

I do not see any get/put functionality in include/linux/tpm.h.

> This is a well trodden pattern in the kernel, there is no reason to do
> something different for tpm.

/Jarkko

Re: [PATCH] tpm: move struct tpm_class_ops to drivers/char/tpm/tpm.h

[Jarkko Sakkinen]

On Sun, Sep 04, 2016 at 02:14:06PM -0600, Jason Gunthorpe wrote:
> On Sat, Sep 03, 2016 at 09:26:05AM +0300, Jarkko Sakkinen wrote:
> > > 
> > > OK, how would one get the chip instance?
> 
> Most subsystems have a get function that returns a kref'd pointer. For
> TPM all we really need today is a 'get_default_tpm_for_ns' kind of
> function.

Sorry, but I have no idea what you are talking about.

This does not imply that these structure definitions need to be in
include/linux/tpm.h since you are talking something that does not exist.

> > This still doesn't explain why moving the structures inside the driver
> > would be wrong. Even if outside callers would use a pointer the
> > structure could be opaque.
> 
> For instance, if we did a get function then the 'put' function would
> be an inline around dev_put and that needs to see inside the chip.

I do not see any get/put functionality in include/linux/tpm.h.

> This is a well trodden pattern in the kernel, there is no reason to do
> something different for tpm.

/Jarkko

Re: [PATCH v5 2/4] tracing: Add cpu as a key field in histogram

[Daniel Wagner]

Hi Binoy

On 09/02/2016 02:37 PM, Binoy Jayan wrote:
> The field 'cpu' although part of the set of generic fields, is not made
> part of the key fields when mentioned in the trigger command. This hack
> suggested by Daniel marks it as one of the key fields and make it appear
> in the histogram output.

While you are at it, why not adding the COMM as well? I know there is
already the common_pid.execname. With only a few extra lines we get COMM
as well and it allows to write something like

hist:key=cpu,comm:sort=cpu,comm

for example.

cheers,
daniel



>From cc2f610078ebe9ba8d850cbf602aa529df690cdb Mon Sep 17 00:00:00 2001
From: Daniel Wagner 
Date: Wed, 31 Aug 2016 09:37:38 +0200
Subject: [PATCH] tracing: Add hist trigger support for generic fields

Whenever a trace is printed the generic fields (CPU, COMM) are
reconstructed (see trace_print_context()). CPU is taken from the
trace_iterator and COMM is extracted from the savedcmd map (see
__trace_find_cmdline()).

We can't reconstruct this information for hist events. Therefore this
information needs to stored when a new event is added to the hist
buffer.

There is already support for extracting the COMM for the common_pid
field. For this the tracing_map_ops infrasture is used. Unfortantly, we
can't reuse it because it extends an existing hist_field. That means we
first need to add a hist_field before we are able to make reuse of
trace_map_ops.

Furthermore, it is quite easy to extend the current code to support
those two fields by adding hist_field_cpu() and hist_field_comm().

Signed-off-by: Daniel Wagner 
Cc: Steven Rostedt 
Cc: Tom Zanussi 
Cc: Binoy Jayan 
---
 kernel/trace/trace.h |  6 ++
 kernel/trace/trace_events.c  | 13 +++--
 kernel/trace/trace_events_hist.c | 31 ---
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f783df4..2b8889b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1288,6 +1288,12 @@ static inline bool is_function_field(struct 
ftrace_event_field *field)
return field->filter_type == FILTER_TRACE_FN;
 }
 
+static inline bool is_generic_field(struct ftrace_event_field *field)
+{
+   return field->filter_type == FILTER_CPU ||
+  field->filter_type == FILTER_COMM;
+}
+
 extern enum regex_type
 filter_parse_regex(char *buff, int len, char **search, int *not);
 extern void print_event_filter(struct trace_event_file *file,
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 03c0a48..7d9154d 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -150,9 +150,10 @@ int trace_define_field(struct trace_event_call *call, 
const char *type,
 }
 EXPORT_SYMBOL_GPL(trace_define_field);
 
-#define __generic_field(type, item, filter_type)   \
+#define __generic_field(type, item, filter_type, size) \
ret = __trace_define_field(_generic_fields, #type,   \
-  #item, 0, 0, is_signed_type(type),   \
+  #item, 0, size,  \
+  is_signed_type(type),\
   filter_type);\
if (ret)\
return ret;
@@ -170,10 +171,10 @@ static int trace_define_generic_fields(void)
 {
int ret;
 
-   __generic_field(int, CPU, FILTER_CPU);
-   __generic_field(int, cpu, FILTER_CPU);
-   __generic_field(char *, COMM, FILTER_COMM);
-   __generic_field(char *, comm, FILTER_COMM);
+   __generic_field(int, CPU, FILTER_CPU, sizeof(int));
+   __generic_field(int, cpu, FILTER_CPU, sizeof(int));
+   __generic_field(char *, COMM, FILTER_COMM, TASK_COMM_LEN + 1);
+   __generic_field(char *, comm, FILTER_COMM, TASK_COMM_LEN + 1);
 
return ret;
 }
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index f3a960e..0b40f22 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -75,6 +75,16 @@ static u64 hist_field_log2(struct hist_field *hist_field, 
void *event)
return (u64) ilog2(roundup_pow_of_two(val));
 }
 
+static u64 hist_field_cpu(struct hist_field *hist_field, void *event)
+{
+   return (u64) smp_processor_id();
+}
+
+static u64 hist_field_comm(struct hist_field *hist_field, void *event)
+{
+   return (u64)(unsigned long)current->comm;
+}
+
 #define DEFINE_HIST_FIELD_FN(type) \
 static u64 hist_field_##type(struct hist_field *hist_field, void *event)\
 {  \
@@ -119,6 +129,7 @@ enum hist_field_flags {

Re: [PATCH v5 2/4] tracing: Add cpu as a key field in histogram

[Daniel Wagner]

Hi Binoy

On 09/02/2016 02:37 PM, Binoy Jayan wrote:
> The field 'cpu' although part of the set of generic fields, is not made
> part of the key fields when mentioned in the trigger command. This hack
> suggested by Daniel marks it as one of the key fields and make it appear
> in the histogram output.

While you are at it, why not adding the COMM as well? I know there is
already the common_pid.execname. With only a few extra lines we get COMM
as well and it allows to write something like

hist:key=cpu,comm:sort=cpu,comm

for example.

cheers,
daniel



>From cc2f610078ebe9ba8d850cbf602aa529df690cdb Mon Sep 17 00:00:00 2001
From: Daniel Wagner 
Date: Wed, 31 Aug 2016 09:37:38 +0200
Subject: [PATCH] tracing: Add hist trigger support for generic fields

Whenever a trace is printed the generic fields (CPU, COMM) are
reconstructed (see trace_print_context()). CPU is taken from the
trace_iterator and COMM is extracted from the savedcmd map (see
__trace_find_cmdline()).

We can't reconstruct this information for hist events. Therefore this
information needs to stored when a new event is added to the hist
buffer.

There is already support for extracting the COMM for the common_pid
field. For this the tracing_map_ops infrasture is used. Unfortantly, we
can't reuse it because it extends an existing hist_field. That means we
first need to add a hist_field before we are able to make reuse of
trace_map_ops.

Furthermore, it is quite easy to extend the current code to support
those two fields by adding hist_field_cpu() and hist_field_comm().

Signed-off-by: Daniel Wagner 
Cc: Steven Rostedt 
Cc: Tom Zanussi 
Cc: Binoy Jayan 
---
 kernel/trace/trace.h |  6 ++
 kernel/trace/trace_events.c  | 13 +++--
 kernel/trace/trace_events_hist.c | 31 ---
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f783df4..2b8889b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1288,6 +1288,12 @@ static inline bool is_function_field(struct 
ftrace_event_field *field)
return field->filter_type == FILTER_TRACE_FN;
 }
 
+static inline bool is_generic_field(struct ftrace_event_field *field)
+{
+   return field->filter_type == FILTER_CPU ||
+  field->filter_type == FILTER_COMM;
+}
+
 extern enum regex_type
 filter_parse_regex(char *buff, int len, char **search, int *not);
 extern void print_event_filter(struct trace_event_file *file,
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 03c0a48..7d9154d 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -150,9 +150,10 @@ int trace_define_field(struct trace_event_call *call, 
const char *type,
 }
 EXPORT_SYMBOL_GPL(trace_define_field);
 
-#define __generic_field(type, item, filter_type)   \
+#define __generic_field(type, item, filter_type, size) \
ret = __trace_define_field(_generic_fields, #type,   \
-  #item, 0, 0, is_signed_type(type),   \
+  #item, 0, size,  \
+  is_signed_type(type),\
   filter_type);\
if (ret)\
return ret;
@@ -170,10 +171,10 @@ static int trace_define_generic_fields(void)
 {
int ret;
 
-   __generic_field(int, CPU, FILTER_CPU);
-   __generic_field(int, cpu, FILTER_CPU);
-   __generic_field(char *, COMM, FILTER_COMM);
-   __generic_field(char *, comm, FILTER_COMM);
+   __generic_field(int, CPU, FILTER_CPU, sizeof(int));
+   __generic_field(int, cpu, FILTER_CPU, sizeof(int));
+   __generic_field(char *, COMM, FILTER_COMM, TASK_COMM_LEN + 1);
+   __generic_field(char *, comm, FILTER_COMM, TASK_COMM_LEN + 1);
 
return ret;
 }
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index f3a960e..0b40f22 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -75,6 +75,16 @@ static u64 hist_field_log2(struct hist_field *hist_field, 
void *event)
return (u64) ilog2(roundup_pow_of_two(val));
 }
 
+static u64 hist_field_cpu(struct hist_field *hist_field, void *event)
+{
+   return (u64) smp_processor_id();
+}
+
+static u64 hist_field_comm(struct hist_field *hist_field, void *event)
+{
+   return (u64)(unsigned long)current->comm;
+}
+
 #define DEFINE_HIST_FIELD_FN(type) \
 static u64 hist_field_##type(struct hist_field *hist_field, void *event)\
 {  \
@@ -119,6 +129,7 @@ enum hist_field_flags {
HIST_FIELD_FL_SYSCALL   = 128,
HIST_FIELD_FL_STACKTRACE= 256,
HIST_FIELD_FL_LOG2  = 512,
+ 

Re: [Question] about patch: don't use [delayed_]work_pending()

[qiaozhou]

On 2016年09月02日 22:21, Tejun Heo wrote:

On Fri, Sep 02, 2016 at 09:50:07AM -0400, Tejun Heo wrote:

Hello,

On Fri, Sep 02, 2016 at 09:17:04AM +0800, qiaozhou wrote:

I don't know whether it's meaningful to still check pending work here, or
it's not suggested to use pm_qos_update_request in this early boot up phase.
Could you help to share some opinions? (I can fix this issue by adding the
current qos value directly instead of default value, though.)

Hmmm... but I suppose this is super-early in the boot.  Would it make
sense to have a static variable (e.g. bool clk_fully_initailized) to
gate the cancel_delayed_sync() call?

You're right that it's indeed super-early stage. But currently we can't
control the gate of can_delayed_work_sync, since it's inside
pm_qos_update_request. Out of our control. We can choose to not call
pm_qos_update_request to avoid this issue, and use pm_qos_add_request
alternatively. Good to have it.

Ah sorry, didn't understand that the offending cancel_sync call is in
the generic part.  Hmm... but yeah, we should still be able to take
the same approach.  I'll see what's the right thing to gate the
operation there.

Does the following patch work?

The patch can fix this issue. Thanks a lot.


Subject: power: avoid calling cancel_delayed_work_sync() during early boot

of_clk_init() ends up calling into pm_qos_update_request() very early
during boot where irq is expected to stay disabled.
pm_qos_update_request() uses cancel_delayed_work_sync() which
correctly assumes that irq is enabled on invocation and
unconditionally disables and re-enables it.

Gate cancel_delayed_work_sync() invocation with kevented_up() to avoid
enabling irq unexpectedly during early boot.

Signed-off-by: Tejun Heo 
Reported-by: Qiao Zhou 
Link: http://lkml.kernel.org/r/d2501c4c-8e7b-bea3-1b01-000b36b5d...@asrmicro.com
---
  kernel/power/qos.c |   11 ++-
   1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 97b0df7..168ff44 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -482,7 +482,16 @@ void pm_qos_update_request(struct pm_qos_request *req,
return;
}
  
-	cancel_delayed_work_sync(>work);

+   /*
+* This function may be called very early during boot, for example,
+* from of_clk_init(), where irq needs to stay disabled.
+* cancel_delayed_work_sync() assumes that irq is enabled on
+* invocation and re-enables it on return.  Avoid calling it until
+* workqueue is initialized.
+*/
+   if (keventd_up())
+   cancel_delayed_work_sync(>work);
+
__pm_qos_update_request(req, new_value);
  }
  EXPORT_SYMBOL_GPL(pm_qos_update_request);

Re: [Question] about patch: don't use [delayed_]work_pending()

[qiaozhou]

On 2016年09月02日 22:21, Tejun Heo wrote:

On Fri, Sep 02, 2016 at 09:50:07AM -0400, Tejun Heo wrote:

Hello,

On Fri, Sep 02, 2016 at 09:17:04AM +0800, qiaozhou wrote:

I don't know whether it's meaningful to still check pending work here, or
it's not suggested to use pm_qos_update_request in this early boot up phase.
Could you help to share some opinions? (I can fix this issue by adding the
current qos value directly instead of default value, though.)

Hmmm... but I suppose this is super-early in the boot.  Would it make
sense to have a static variable (e.g. bool clk_fully_initailized) to
gate the cancel_delayed_sync() call?

You're right that it's indeed super-early stage. But currently we can't
control the gate of can_delayed_work_sync, since it's inside
pm_qos_update_request. Out of our control. We can choose to not call
pm_qos_update_request to avoid this issue, and use pm_qos_add_request
alternatively. Good to have it.

Ah sorry, didn't understand that the offending cancel_sync call is in
the generic part.  Hmm... but yeah, we should still be able to take
the same approach.  I'll see what's the right thing to gate the
operation there.

Does the following patch work?

The patch can fix this issue. Thanks a lot.


Subject: power: avoid calling cancel_delayed_work_sync() during early boot

of_clk_init() ends up calling into pm_qos_update_request() very early
during boot where irq is expected to stay disabled.
pm_qos_update_request() uses cancel_delayed_work_sync() which
correctly assumes that irq is enabled on invocation and
unconditionally disables and re-enables it.

Gate cancel_delayed_work_sync() invocation with kevented_up() to avoid
enabling irq unexpectedly during early boot.

Signed-off-by: Tejun Heo 
Reported-by: Qiao Zhou 
Link: http://lkml.kernel.org/r/d2501c4c-8e7b-bea3-1b01-000b36b5d...@asrmicro.com
---
  kernel/power/qos.c |   11 ++-
   1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 97b0df7..168ff44 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -482,7 +482,16 @@ void pm_qos_update_request(struct pm_qos_request *req,
return;
}
  
-	cancel_delayed_work_sync(>work);

+   /*
+* This function may be called very early during boot, for example,
+* from of_clk_init(), where irq needs to stay disabled.
+* cancel_delayed_work_sync() assumes that irq is enabled on
+* invocation and re-enables it on return.  Avoid calling it until
+* workqueue is initialized.
+*/
+   if (keventd_up())
+   cancel_delayed_work_sync(>work);
+
__pm_qos_update_request(req, new_value);
  }
  EXPORT_SYMBOL_GPL(pm_qos_update_request);

Re: [PATCH v2] pwm: berlin: Add PM support

[Thierry Reding]

On Wed, Nov 25, 2015 at 05:41:25PM +0800, Jisheng Zhang wrote:
> This patch adds S2R support for berlin pwm driver.
> 
> Signed-off-by: Jisheng Zhang 
> ---
> Since v1:
>  - implement .request and .free hooks, allocate/free the channel in
>berlin_pwm_request/berlin_pwm_free. Then use pwm_get_chip_data in
>suspend/resume implementation.
>  - s/int/unsigned int
>  - check return value of clk_prepare_enable
>  - remoev BERLIN_PWM_PM_OPS macro
>  drivers/pwm/pwm-berlin.c | 90 
> +++-
>  1 file changed, 89 insertions(+), 1 deletion(-)

Sorry, I had completely missed this. Applied now, with some minor
stylistic changes.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2] pwm: berlin: Add PM support

[Thierry Reding]

On Wed, Nov 25, 2015 at 05:41:25PM +0800, Jisheng Zhang wrote:
> This patch adds S2R support for berlin pwm driver.
> 
> Signed-off-by: Jisheng Zhang 
> ---
> Since v1:
>  - implement .request and .free hooks, allocate/free the channel in
>berlin_pwm_request/berlin_pwm_free. Then use pwm_get_chip_data in
>suspend/resume implementation.
>  - s/int/unsigned int
>  - check return value of clk_prepare_enable
>  - remoev BERLIN_PWM_PM_OPS macro
>  drivers/pwm/pwm-berlin.c | 90 
> +++-
>  1 file changed, 89 insertions(+), 1 deletion(-)

Sorry, I had completely missed this. Applied now, with some minor
stylistic changes.

Thanks,
Thierry


signature.asc
Description: PGP signature

[PATCH v8 3/7] perf config: Add default section and item arrays for 'colors' config

[Taeung Song]

Actual values for default configs of 'colors' section is like below.

(at ui/browser.c)
static struct ui_browser_colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
.fg   = "red",
.bg   = "default",
},
...

But I suggest using default config arrays for 'colors' section that
contain all default config key-value pairs for it.

In near future, this array will be used on ui/browser.c
because of setting default values of actual variables for 'colors' config.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.c | 15 +++
 tools/perf/util/config.h | 17 +
 2 files changed, 32 insertions(+)

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 18dae74..a0c0170 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -30,6 +30,21 @@ static struct perf_config_set *config_set;
 
 const char *config_exclusive_filename;
 
+const struct default_config_item colors_config_items[] = {
+   CONF_STR_VAR("top", "red, default"),
+   CONF_STR_VAR("medium", "green, default"),
+   CONF_STR_VAR("normal", "default, default"),
+   CONF_STR_VAR("selected", "black, yellow"),
+   CONF_STR_VAR("jump_arrows", "blue, default"),
+   CONF_STR_VAR("addr", "magenta, default"),
+   CONF_STR_VAR("root", "white, blue"),
+   CONF_END()
+};
+
+const struct default_config_section default_sections[] = {
+   { .name = "colors", .items = colors_config_items },
+};
+
 static int get_next_char(void)
 {
int c;
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 613900f..b9190fe 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -73,6 +73,20 @@ enum perf_config_type {
CONFIG_TYPE_STRING
 };
 
+enum config_section_idx {
+   CONFIG_COLORS,
+};
+
+enum colors_config_items_idx {
+   CONFIG_COLORS_TOP,
+   CONFIG_COLORS_MEDIUM,
+   CONFIG_COLORS_NORMAL,
+   CONFIG_COLORS_SELECTED,
+   CONFIG_COLORS_JUMP_ARROWS,
+   CONFIG_COLORS_ADDR,
+   CONFIG_COLORS_ROOT,
+};
+
 struct default_config_item {
const char *name;
union {
@@ -112,4 +126,7 @@ struct default_config_section {
 #define CONF_END() \
{ .name = NULL }
 
+extern const struct default_config_section default_sections[];
+extern const struct default_config_item colors_config_items[];
+
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 6/7] perf config: Add default section and item arrays for 'annotate' config

[Taeung Song]

Actual values for default configs of 'annotate' section is like below.

(at ui/browsers/annoate.c)
static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
 jump_arrows,
 show_linenr,
 show_nr_jumps,
 show_total_period;
} annotate_browser__opts = {
.use_offset  = true,
.jump_arrows = true,
};

But I suggest using default config arrays for 'annotate' section that
contain all default config key-value pairs for it.

In near future, this arrays will be used on ui/browsers/annoate.c
because of setting default values of actual variables for 'annotate' config.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.c | 11 +++
 tools/perf/util/config.h | 11 +++
 2 files changed, 22 insertions(+)

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index a0c0170..d8d5415 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -41,8 +41,19 @@ const struct default_config_item colors_config_items[] = {
CONF_END()
 };
 
+const struct default_config_item annotate_config_items[] = {
+   CONF_BOOL_VAR("hide_src_code", false),
+   CONF_BOOL_VAR("use_offset", true),
+   CONF_BOOL_VAR("jump_arrows", true),
+   CONF_BOOL_VAR("show_nr_jumps", false),
+   CONF_BOOL_VAR("show_linenr", false),
+   CONF_BOOL_VAR("show_total_period", false),
+   CONF_END()
+};
+
 const struct default_config_section default_sections[] = {
{ .name = "colors", .items = colors_config_items },
+   { .name = "annotate", .items = annotate_config_items },
 };
 
 static int get_next_char(void)
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index b9190fe..2fcfd51 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -75,6 +75,7 @@ enum perf_config_type {
 
 enum config_section_idx {
CONFIG_COLORS,
+   CONFIG_ANNOTATE,
 };
 
 enum colors_config_items_idx {
@@ -87,6 +88,15 @@ enum colors_config_items_idx {
CONFIG_COLORS_ROOT,
 };
 
+enum annotate_config_items_idx {
+   CONFIG_ANNOTATE_HIDE_SRC_CODE,
+   CONFIG_ANNOTATE_USE_OFFSET,
+   CONFIG_ANNOTATE_JUMP_ARROWS,
+   CONFIG_ANNOTATE_SHOW_NR_JUMPS,
+   CONFIG_ANNOTATE_SHOW_LINENR,
+   CONFIG_ANNOTATE_SHOW_TOTAL_PERIOD,
+};
+
 struct default_config_item {
const char *name;
union {
@@ -128,5 +138,6 @@ struct default_config_section {
 
 extern const struct default_config_section default_sections[];
 extern const struct default_config_item colors_config_items[];
+extern const struct default_config_item annotate_config_items[];
 
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 6/7] perf config: Add default section and item arrays for 'annotate' config

[Taeung Song]

Actual values for default configs of 'annotate' section is like below.

(at ui/browsers/annoate.c)
static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
 jump_arrows,
 show_linenr,
 show_nr_jumps,
 show_total_period;
} annotate_browser__opts = {
.use_offset  = true,
.jump_arrows = true,
};

But I suggest using default config arrays for 'annotate' section that
contain all default config key-value pairs for it.

In near future, this arrays will be used on ui/browsers/annoate.c
because of setting default values of actual variables for 'annotate' config.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.c | 11 +++
 tools/perf/util/config.h | 11 +++
 2 files changed, 22 insertions(+)

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index a0c0170..d8d5415 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -41,8 +41,19 @@ const struct default_config_item colors_config_items[] = {
CONF_END()
 };
 
+const struct default_config_item annotate_config_items[] = {
+   CONF_BOOL_VAR("hide_src_code", false),
+   CONF_BOOL_VAR("use_offset", true),
+   CONF_BOOL_VAR("jump_arrows", true),
+   CONF_BOOL_VAR("show_nr_jumps", false),
+   CONF_BOOL_VAR("show_linenr", false),
+   CONF_BOOL_VAR("show_total_period", false),
+   CONF_END()
+};
+
 const struct default_config_section default_sections[] = {
{ .name = "colors", .items = colors_config_items },
+   { .name = "annotate", .items = annotate_config_items },
 };
 
 static int get_next_char(void)
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index b9190fe..2fcfd51 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -75,6 +75,7 @@ enum perf_config_type {
 
 enum config_section_idx {
CONFIG_COLORS,
+   CONFIG_ANNOTATE,
 };
 
 enum colors_config_items_idx {
@@ -87,6 +88,15 @@ enum colors_config_items_idx {
CONFIG_COLORS_ROOT,
 };
 
+enum annotate_config_items_idx {
+   CONFIG_ANNOTATE_HIDE_SRC_CODE,
+   CONFIG_ANNOTATE_USE_OFFSET,
+   CONFIG_ANNOTATE_JUMP_ARROWS,
+   CONFIG_ANNOTATE_SHOW_NR_JUMPS,
+   CONFIG_ANNOTATE_SHOW_LINENR,
+   CONFIG_ANNOTATE_SHOW_TOTAL_PERIOD,
+};
+
 struct default_config_item {
const char *name;
union {
@@ -128,5 +138,6 @@ struct default_config_section {
 
 extern const struct default_config_section default_sections[];
 extern const struct default_config_item colors_config_items[];
+extern const struct default_config_item annotate_config_items[];
 
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 3/7] perf config: Add default section and item arrays for 'colors' config

[Taeung Song]

Actual values for default configs of 'colors' section is like below.

(at ui/browser.c)
static struct ui_browser_colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
.fg   = "red",
.bg   = "default",
},
...

But I suggest using default config arrays for 'colors' section that
contain all default config key-value pairs for it.

In near future, this array will be used on ui/browser.c
because of setting default values of actual variables for 'colors' config.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.c | 15 +++
 tools/perf/util/config.h | 17 +
 2 files changed, 32 insertions(+)

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 18dae74..a0c0170 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -30,6 +30,21 @@ static struct perf_config_set *config_set;
 
 const char *config_exclusive_filename;
 
+const struct default_config_item colors_config_items[] = {
+   CONF_STR_VAR("top", "red, default"),
+   CONF_STR_VAR("medium", "green, default"),
+   CONF_STR_VAR("normal", "default, default"),
+   CONF_STR_VAR("selected", "black, yellow"),
+   CONF_STR_VAR("jump_arrows", "blue, default"),
+   CONF_STR_VAR("addr", "magenta, default"),
+   CONF_STR_VAR("root", "white, blue"),
+   CONF_END()
+};
+
+const struct default_config_section default_sections[] = {
+   { .name = "colors", .items = colors_config_items },
+};
+
 static int get_next_char(void)
 {
int c;
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 613900f..b9190fe 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -73,6 +73,20 @@ enum perf_config_type {
CONFIG_TYPE_STRING
 };
 
+enum config_section_idx {
+   CONFIG_COLORS,
+};
+
+enum colors_config_items_idx {
+   CONFIG_COLORS_TOP,
+   CONFIG_COLORS_MEDIUM,
+   CONFIG_COLORS_NORMAL,
+   CONFIG_COLORS_SELECTED,
+   CONFIG_COLORS_JUMP_ARROWS,
+   CONFIG_COLORS_ADDR,
+   CONFIG_COLORS_ROOT,
+};
+
 struct default_config_item {
const char *name;
union {
@@ -112,4 +126,7 @@ struct default_config_section {
 #define CONF_END() \
{ .name = NULL }
 
+extern const struct default_config_section default_sections[];
+extern const struct default_config_item colors_config_items[];
+
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 2/7] perf config: Add macros assigning key-value pairs to default_config_item

[Taeung Song]

In near future, default_config_item arrays will be added
(e.g. const struct default_config_item colors_config_items[])
To simply assign config key-value pairs to default_config_item,
add macros that are CONF_VAR() and CONF_*_VAR() for each type.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Wang Nan 
Cc: Masami Hiramatsu 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 1fd8e4c..613900f 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -92,4 +92,24 @@ struct default_config_section {
const struct default_config_item *items;
 };
 
+#define CONF_VAR(_name, _field, _val, _type)   \
+   { .name = _name, .value._field = _val, .type = _type }
+
+#define CONF_BOOL_VAR(_name, _val) \
+   CONF_VAR(_name, b, _val, CONFIG_TYPE_BOOL)
+#define CONF_INT_VAR(_name, _val)  \
+   CONF_VAR(_name, i, _val, CONFIG_TYPE_INT)
+#define CONF_LONG_VAR(_name, _val) \
+   CONF_VAR(_name, l, _val, CONFIG_TYPE_LONG)
+#define CONF_U64_VAR(_name, _val)  \
+   CONF_VAR(_name, ll, _val, CONFIG_TYPE_U64)
+#define CONF_FLOAT_VAR(_name, _val)\
+   CONF_VAR(_name, f, _val, CONFIG_TYPE_FLOAT)
+#define CONF_DOUBLE_VAR(_name, _val)   \
+   CONF_VAR(_name, d, _val, CONFIG_TYPE_DOUBLE)
+#define CONF_STR_VAR(_name, _val)  \
+   CONF_VAR(_name, s, _val, CONFIG_TYPE_STRING)
+#define CONF_END() \
+   { .name = NULL }
+
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 5/7] perf config: Initialize ui_browser__colorsets with default config items

[Taeung Song]

Set default config values for 'colors' section with 'colors_config_items[]'
instead of actual const char * type values.
(e.g. using colors_config_item[CONFIG_COLORS_TOP].value.s
instead of "red, default" string value for 'colors.top')

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browser.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 1c80f00..5caa7e4 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -509,37 +509,30 @@ static struct ui_browser_colorset {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
-   .colors   = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
-   .colors   = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
-   .colors   = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
-   .colors   = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
-   .colors   = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
-   .colors   = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
-   .colors   = "white, blue",
},
{
.name = NULL,
@@ -724,10 +717,28 @@ void __ui_browser__line_arrow(struct ui_browser *browser, 
unsigned int column,
__ui_browser__line_arrow_down(browser, column, start, end);
 }
 
+static void default_colors_config_init(void)
+{
+   int i, j;
+
+   for (i = 0; ui_browser__colorsets[i].name != NULL; ++i) {
+   const char *name = ui_browser__colorsets[i].name;
+
+   for (j = 0; colors_config_items[j].name != NULL; j++) {
+   if (!strcmp(name, colors_config_items[j].name)) {
+   ui_browser__colorsets[i].colors =
+   colors_config_items[j].value.s;
+   break;
+   }
+   }
+   }
+}
+
 void ui_browser__init(void)
 {
int i = 0;
 
+   default_colors_config_init();
perf_config(ui_browser__color_config, NULL);
 
while (ui_browser__colorsets[i].name) {
-- 
2.7.4

[PATCH v8 2/7] perf config: Add macros assigning key-value pairs to default_config_item

[Taeung Song]

In near future, default_config_item arrays will be added
(e.g. const struct default_config_item colors_config_items[])
To simply assign config key-value pairs to default_config_item,
add macros that are CONF_VAR() and CONF_*_VAR() for each type.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Wang Nan 
Cc: Masami Hiramatsu 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 1fd8e4c..613900f 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -92,4 +92,24 @@ struct default_config_section {
const struct default_config_item *items;
 };
 
+#define CONF_VAR(_name, _field, _val, _type)   \
+   { .name = _name, .value._field = _val, .type = _type }
+
+#define CONF_BOOL_VAR(_name, _val) \
+   CONF_VAR(_name, b, _val, CONFIG_TYPE_BOOL)
+#define CONF_INT_VAR(_name, _val)  \
+   CONF_VAR(_name, i, _val, CONFIG_TYPE_INT)
+#define CONF_LONG_VAR(_name, _val) \
+   CONF_VAR(_name, l, _val, CONFIG_TYPE_LONG)
+#define CONF_U64_VAR(_name, _val)  \
+   CONF_VAR(_name, ll, _val, CONFIG_TYPE_U64)
+#define CONF_FLOAT_VAR(_name, _val)\
+   CONF_VAR(_name, f, _val, CONFIG_TYPE_FLOAT)
+#define CONF_DOUBLE_VAR(_name, _val)   \
+   CONF_VAR(_name, d, _val, CONFIG_TYPE_DOUBLE)
+#define CONF_STR_VAR(_name, _val)  \
+   CONF_VAR(_name, s, _val, CONFIG_TYPE_STRING)
+#define CONF_END() \
+   { .name = NULL }
+
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 5/7] perf config: Initialize ui_browser__colorsets with default config items

[Taeung Song]

Set default config values for 'colors' section with 'colors_config_items[]'
instead of actual const char * type values.
(e.g. using colors_config_item[CONFIG_COLORS_TOP].value.s
instead of "red, default" string value for 'colors.top')

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browser.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 1c80f00..5caa7e4 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -509,37 +509,30 @@ static struct ui_browser_colorset {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
-   .colors   = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
-   .colors   = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
-   .colors   = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
-   .colors   = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
-   .colors   = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
-   .colors   = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
-   .colors   = "white, blue",
},
{
.name = NULL,
@@ -724,10 +717,28 @@ void __ui_browser__line_arrow(struct ui_browser *browser, 
unsigned int column,
__ui_browser__line_arrow_down(browser, column, start, end);
 }
 
+static void default_colors_config_init(void)
+{
+   int i, j;
+
+   for (i = 0; ui_browser__colorsets[i].name != NULL; ++i) {
+   const char *name = ui_browser__colorsets[i].name;
+
+   for (j = 0; colors_config_items[j].name != NULL; j++) {
+   if (!strcmp(name, colors_config_items[j].name)) {
+   ui_browser__colorsets[i].colors =
+   colors_config_items[j].value.s;
+   break;
+   }
+   }
+   }
+}
+
 void ui_browser__init(void)
 {
int i = 0;
 
+   default_colors_config_init();
perf_config(ui_browser__color_config, NULL);
 
while (ui_browser__colorsets[i].name) {
-- 
2.7.4

[PATCH v8 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

[Taeung Song]

To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
have only one value like 'default_config_item' type.

If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to initialize default config values for 'colors' config
by 'colors_config_items' array that contains default values for it at 
util/config.c.
because both actual variable and config item of 'colors_config_items'
are equal in the number of values (as just one).

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browser.c | 53 +++--
 1 file changed, 25 insertions(+), 28 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 3eb3edb..1c80f00 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -503,61 +503,53 @@ unsigned int ui_browser__list_head_refresh(struct 
ui_browser *browser)
 }
 
 static struct ui_browser_colorset {
-   const char *name, *fg, *bg;
+   const char *name, *colors;
int colorset;
 } ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
-   .fg   = "red",
-   .bg   = "default",
+   .colors   = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
-   .fg   = "green",
-   .bg   = "default",
+   .colors   = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
-   .fg   = "default",
-   .bg   = "default",
+   .colors   = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
-   .fg   = "black",
-   .bg   = "yellow",
+   .colors   = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
-   .fg   = "blue",
-   .bg   = "default",
+   .colors   = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
-   .fg   = "magenta",
-   .bg   = "default",
+   .colors   = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
-   .fg   = "white",
-   .bg   = "blue",
+   .colors   = "white, blue",
},
{
.name = NULL,
}
 };
 
-
 static int ui_browser__color_config(const char *var, const char *value,
void *data __maybe_unused)
 {
-   char *fg = NULL, *bg;
+   char *colors;
int i;
 
/* same dir for all commands */
@@ -570,22 +562,18 @@ static int ui_browser__color_config(const char *var, 
const char *value,
if (strcmp(ui_browser__colorsets[i].name, name) != 0)
continue;
 
-   fg = strdup(value);
-   if (fg == NULL)
-   break;
+   if (strstr(value, ",") == NULL)
+   return -1;
 
-   bg = strchr(fg, ',');
-   if (bg == NULL)
+   colors = strdup(value);
+   if (colors == NULL)
break;
+   ui_browser__colorsets[i].colors = colors;
 
-   *bg = '\0';
-   while (isspace(*++bg));
-   ui_browser__colorsets[i].bg = bg;
-   ui_browser__colorsets[i].fg = fg;
return 0;
}
 
-   free(fg);
+   free(colors);
return -1;
 }
 
@@ -743,8 +731,17 @@ void ui_browser__init(void)
perf_config(ui_browser__color_config, NULL);
 
while (ui_browser__colorsets[i].name) {
+   char *colors, *fg, *bg;
struct ui_browser_colorset *c = _browser__colorsets[i++];
-   sltt_set_color(c->colorset, c->name, c->fg, c->bg);
+
+   colors = strdup(c->colors);
+   if (colors == NULL)
+   break;
+   fg = strtok(colors, ",");
+   bg = strtok(NULL, ",");
+   bg = ltrim(bg);
+   sltt_set_color(c->colorset, c->name, fg, bg);
+   free(colors);
}
 
annotate_browser__init();
-- 
2.7.4

[PATCH v8 7/7] perf config: Initialize annotate_browser__opts with default config items

[Taeung Song]

Set default config values for 'annotate' section with 'annotate_config_items[]'
instead of actual bool type values.
(e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value.b
instead of 'true' bool type value for 'annotate.use_offset'.)

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browsers/annotate.c | 16 
 tools/perf/util/config.h  |  3 +++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 4c18271..b5c975c 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -38,10 +38,7 @@ static struct annotate_browser_opt {
 show_linenr,
 show_nr_jumps,
 show_total_period;
-} annotate_browser__opts = {
-   .use_offset = true,
-   .jump_arrows= true,
-};
+} annotate_browser__opts;
 
 struct annotate_browser {
struct ui_browser b;
@@ -1160,7 +1157,18 @@ static int annotate__config(const char *var, const char 
*value,
return 0;
 }
 
+static void default_annotate_config_init(void)
+{
+   annotate_browser__opts.hide_src_code = CONF_DEFAULT_BOOL(ANNOTATE, 
HIDE_SRC_CODE);
+   annotate_browser__opts.use_offset = CONF_DEFAULT_BOOL(ANNOTATE, 
USE_OFFSET);
+   annotate_browser__opts.jump_arrows = CONF_DEFAULT_BOOL(ANNOTATE, 
JUMP_ARROWS);
+   annotate_browser__opts.show_linenr = CONF_DEFAULT_BOOL(ANNOTATE, 
SHOW_LINENR);
+   annotate_browser__opts.show_nr_jumps = CONF_DEFAULT_BOOL(ANNOTATE, 
SHOW_NR_JUMPS);
+   annotate_browser__opts.show_total_period = CONF_DEFAULT_BOOL(ANNOTATE, 
SHOW_TOTAL_PERIOD);
+}
+
 void annotate_browser__init(void)
 {
+   default_annotate_config_init();
perf_config(annotate__config, NULL);
 }
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 2fcfd51..76f5b21 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -136,6 +136,9 @@ struct default_config_section {
 #define CONF_END() \
{ .name = NULL }
 
+#define CONF_DEFAULT_BOOL(sec, name)   \
+   default_sections[CONFIG_##sec].items[CONFIG_##sec##_##name].value.b
+
 extern const struct default_config_section default_sections[];
 extern const struct default_config_item colors_config_items[];
 extern const struct default_config_item annotate_config_items[];
-- 
2.7.4

[PATCH v8 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

[Taeung Song]

To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
have only one value like 'default_config_item' type.

If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to initialize default config values for 'colors' config
by 'colors_config_items' array that contains default values for it at 
util/config.c.
because both actual variable and config item of 'colors_config_items'
are equal in the number of values (as just one).

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browser.c | 53 +++--
 1 file changed, 25 insertions(+), 28 deletions(-)

diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 3eb3edb..1c80f00 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -503,61 +503,53 @@ unsigned int ui_browser__list_head_refresh(struct 
ui_browser *browser)
 }
 
 static struct ui_browser_colorset {
-   const char *name, *fg, *bg;
+   const char *name, *colors;
int colorset;
 } ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
-   .fg   = "red",
-   .bg   = "default",
+   .colors   = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
-   .fg   = "green",
-   .bg   = "default",
+   .colors   = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
-   .fg   = "default",
-   .bg   = "default",
+   .colors   = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
-   .fg   = "black",
-   .bg   = "yellow",
+   .colors   = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
-   .fg   = "blue",
-   .bg   = "default",
+   .colors   = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
-   .fg   = "magenta",
-   .bg   = "default",
+   .colors   = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
-   .fg   = "white",
-   .bg   = "blue",
+   .colors   = "white, blue",
},
{
.name = NULL,
}
 };
 
-
 static int ui_browser__color_config(const char *var, const char *value,
void *data __maybe_unused)
 {
-   char *fg = NULL, *bg;
+   char *colors;
int i;
 
/* same dir for all commands */
@@ -570,22 +562,18 @@ static int ui_browser__color_config(const char *var, 
const char *value,
if (strcmp(ui_browser__colorsets[i].name, name) != 0)
continue;
 
-   fg = strdup(value);
-   if (fg == NULL)
-   break;
+   if (strstr(value, ",") == NULL)
+   return -1;
 
-   bg = strchr(fg, ',');
-   if (bg == NULL)
+   colors = strdup(value);
+   if (colors == NULL)
break;
+   ui_browser__colorsets[i].colors = colors;
 
-   *bg = '\0';
-   while (isspace(*++bg));
-   ui_browser__colorsets[i].bg = bg;
-   ui_browser__colorsets[i].fg = fg;
return 0;
}
 
-   free(fg);
+   free(colors);
return -1;
 }
 
@@ -743,8 +731,17 @@ void ui_browser__init(void)
perf_config(ui_browser__color_config, NULL);
 
while (ui_browser__colorsets[i].name) {
+   char *colors, *fg, *bg;
struct ui_browser_colorset *c = _browser__colorsets[i++];
-   sltt_set_color(c->colorset, c->name, c->fg, c->bg);
+
+   colors = strdup(c->colors);
+   if (colors == NULL)
+   break;
+   fg = strtok(colors, ",");
+   bg = strtok(NULL, ",");
+   bg = ltrim(bg);
+   sltt_set_color(c->colorset, c->name, fg, bg);
+   free(colors);
}
 
annotate_browser__init();
-- 
2.7.4

[PATCH v8 7/7] perf config: Initialize annotate_browser__opts with default config items

[Taeung Song]

Set default config values for 'annotate' section with 'annotate_config_items[]'
instead of actual bool type values.
(e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value.b
instead of 'true' bool type value for 'annotate.use_offset'.)

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Wang Nan 
Signed-off-by: Taeung Song 
---
 tools/perf/ui/browsers/annotate.c | 16 
 tools/perf/util/config.h  |  3 +++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 4c18271..b5c975c 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -38,10 +38,7 @@ static struct annotate_browser_opt {
 show_linenr,
 show_nr_jumps,
 show_total_period;
-} annotate_browser__opts = {
-   .use_offset = true,
-   .jump_arrows= true,
-};
+} annotate_browser__opts;
 
 struct annotate_browser {
struct ui_browser b;
@@ -1160,7 +1157,18 @@ static int annotate__config(const char *var, const char 
*value,
return 0;
 }
 
+static void default_annotate_config_init(void)
+{
+   annotate_browser__opts.hide_src_code = CONF_DEFAULT_BOOL(ANNOTATE, 
HIDE_SRC_CODE);
+   annotate_browser__opts.use_offset = CONF_DEFAULT_BOOL(ANNOTATE, 
USE_OFFSET);
+   annotate_browser__opts.jump_arrows = CONF_DEFAULT_BOOL(ANNOTATE, 
JUMP_ARROWS);
+   annotate_browser__opts.show_linenr = CONF_DEFAULT_BOOL(ANNOTATE, 
SHOW_LINENR);
+   annotate_browser__opts.show_nr_jumps = CONF_DEFAULT_BOOL(ANNOTATE, 
SHOW_NR_JUMPS);
+   annotate_browser__opts.show_total_period = CONF_DEFAULT_BOOL(ANNOTATE, 
SHOW_TOTAL_PERIOD);
+}
+
 void annotate_browser__init(void)
 {
+   default_annotate_config_init();
perf_config(annotate__config, NULL);
 }
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 2fcfd51..76f5b21 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -136,6 +136,9 @@ struct default_config_section {
 #define CONF_END() \
{ .name = NULL }
 
+#define CONF_DEFAULT_BOOL(sec, name)   \
+   default_sections[CONFIG_##sec].items[CONFIG_##sec##_##name].value.b
+
 extern const struct default_config_section default_sections[];
 extern const struct default_config_item colors_config_items[];
 extern const struct default_config_item annotate_config_items[];
-- 
2.7.4

[PATCH v8 1/7] perf config: Introduce default_config_section and default_config_item for default config key-value pairs

[Taeung Song]

When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).

For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default value for it is 'true' bool type value in perf like below.

At ui/browsers/annoate.c

static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
 jump_arrows,
 show_linenr,
 show_nr_jumps,
 show_total_period;
} annotate_browser__opts = {
.use_offset  = true,
.jump_arrows = true,
};

But I suggest using 'struct default_config_section' and
'struct default_config_item' that can contain default config key-value pairs
in order to initialize default config values with them, in near future.

If we do, we could manage default perf config values at one spot (i.e. 
util/config.c)
with default config arrays and it could be easy and simple to modify
existing default config values or add default values for new config item.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Wang Nan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Masami Hiramatsu 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 6f813d4..1fd8e4c 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -63,4 +63,33 @@ void perf_config__refresh(void);
perf_config_sections__for_each_entry(>sections, section)   
\
perf_config_items__for_each_entry(>items, item)
 
+enum perf_config_type {
+   CONFIG_TYPE_BOOL,
+   CONFIG_TYPE_INT,
+   CONFIG_TYPE_LONG,
+   CONFIG_TYPE_U64,
+   CONFIG_TYPE_FLOAT,
+   CONFIG_TYPE_DOUBLE,
+   CONFIG_TYPE_STRING
+};
+
+struct default_config_item {
+   const char *name;
+   union {
+   bool b;
+   int i;
+   u32 l;
+   u64 ll;
+   float f;
+   double d;
+   const char *s;
+   } value;
+   enum perf_config_type type;
+};
+
+struct default_config_section {
+   const char *name;
+   const struct default_config_item *items;
+};
+
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 0/7] perf config: Introduce default config key-value pairs arrays

[Taeung Song]

Hello, :)

When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.

For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default value for it is 'true' bool type value in perf like below.

At ui/browsers/annoate.c

static struct annotate_browser_opt {
   bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
   .use_offset  = true,
   .jump_arrows = true,
};

But if we use new config arrays that have all default config key-value pairs,
we could initialize default config values with them.

If we do, we can manage default perf config values at one spot (like 
util/config.c)
and It can be easy and simple to modify existing default config values or
add default values for new config item.

For example,
If we use new default config arrays and there isn't user config value for 
'annoate.use_offset'
default value for it will be set as 
annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value.b
instead of actual boolean type value 'true'.

IMHO, I think it would needed to use new default config arrays
to manage default perf config values more effectively.
And this pathset contains patchs for only 'colors' and 'annoate' section
because waiting for other opinions.

If you review this patchset, I'd appreciate it :-)

Thanks,
Taeung

v8:
- rebased on current acme/perf/core

v7:
- fix wrong handling a exception from strdup (Arnaldo)
- rebased on current acme/perf/core

v6:
- rename 'fore_back_colors' to simple 'colors' of ui_browser_colorset (Namhyung)
- remove unnecssary whitespace changes of PATCH 4/7, 5/7 (Namhyung)
- make more general macro instead of making accessor macro for each config 
section (Namhyung)
- rebased on current acme/perf/core

v5:
- rebased on current acme/perf/core

v4:
- rename 'fb_ground' to 'fore_back_colors' (Namhyung)
- add struct default_config_section
- split first patch[PATCH 1/7] as two
- remove perf_default_config_init() at perf.c
- rebased on current acme/perf/core

v3:
- remove default config arrays for the rest sections except 'colors' and 
'annotate'
- use combined {fore, back}ground colors instead of each two color
- introduce perf_default_config_init() that call all default_*_config_init()
  for each config section

v2:
- rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' (Arnaldo)
- change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
- use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)

Taeung Song (7):
  perf config: Introduce default_config_section and default_config_item
for default config key-value pairs
  perf config: Add macros assigning key-value pairs to
default_config_item
  perf config: Add default section and item arrays for 'colors' config
  perf config: Use combined {fore,back}ground colors value instead of
each two color
  perf config: Initialize ui_browser__colorsets with default config
items
  perf config: Add default section and item arrays for 'annotate' config
  perf config: Initialize annotate_browser__opts with default config
items

 tools/perf/ui/browser.c   | 64 +--
 tools/perf/ui/browsers/annotate.c | 16 ++--
 tools/perf/util/config.c  | 26 +
 tools/perf/util/config.h  | 80 +++
 4 files changed, 154 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v8 1/7] perf config: Introduce default_config_section and default_config_item for default config key-value pairs

[Taeung Song]

When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).

For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default value for it is 'true' bool type value in perf like below.

At ui/browsers/annoate.c

static struct annotate_browser_opt {
bool hide_src_code,
 use_offset,
 jump_arrows,
 show_linenr,
 show_nr_jumps,
 show_total_period;
} annotate_browser__opts = {
.use_offset  = true,
.jump_arrows = true,
};

But I suggest using 'struct default_config_section' and
'struct default_config_item' that can contain default config key-value pairs
in order to initialize default config values with them, in near future.

If we do, we could manage default perf config values at one spot (i.e. 
util/config.c)
with default config arrays and it could be easy and simple to modify
existing default config values or add default values for new config item.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Wang Nan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Masami Hiramatsu 
Signed-off-by: Taeung Song 
---
 tools/perf/util/config.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 6f813d4..1fd8e4c 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -63,4 +63,33 @@ void perf_config__refresh(void);
perf_config_sections__for_each_entry(>sections, section)   
\
perf_config_items__for_each_entry(>items, item)
 
+enum perf_config_type {
+   CONFIG_TYPE_BOOL,
+   CONFIG_TYPE_INT,
+   CONFIG_TYPE_LONG,
+   CONFIG_TYPE_U64,
+   CONFIG_TYPE_FLOAT,
+   CONFIG_TYPE_DOUBLE,
+   CONFIG_TYPE_STRING
+};
+
+struct default_config_item {
+   const char *name;
+   union {
+   bool b;
+   int i;
+   u32 l;
+   u64 ll;
+   float f;
+   double d;
+   const char *s;
+   } value;
+   enum perf_config_type type;
+};
+
+struct default_config_section {
+   const char *name;
+   const struct default_config_item *items;
+};
+
 #endif /* __PERF_CONFIG_H */
-- 
2.7.4

[PATCH v8 0/7] perf config: Introduce default config key-value pairs arrays

[Taeung Song]

Hello, :)

When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.

For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default value for it is 'true' bool type value in perf like below.

At ui/browsers/annoate.c

static struct annotate_browser_opt {
   bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
   .use_offset  = true,
   .jump_arrows = true,
};

But if we use new config arrays that have all default config key-value pairs,
we could initialize default config values with them.

If we do, we can manage default perf config values at one spot (like 
util/config.c)
and It can be easy and simple to modify existing default config values or
add default values for new config item.

For example,
If we use new default config arrays and there isn't user config value for 
'annoate.use_offset'
default value for it will be set as 
annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value.b
instead of actual boolean type value 'true'.

IMHO, I think it would needed to use new default config arrays
to manage default perf config values more effectively.
And this pathset contains patchs for only 'colors' and 'annoate' section
because waiting for other opinions.

If you review this patchset, I'd appreciate it :-)

Thanks,
Taeung

v8:
- rebased on current acme/perf/core

v7:
- fix wrong handling a exception from strdup (Arnaldo)
- rebased on current acme/perf/core

v6:
- rename 'fore_back_colors' to simple 'colors' of ui_browser_colorset (Namhyung)
- remove unnecssary whitespace changes of PATCH 4/7, 5/7 (Namhyung)
- make more general macro instead of making accessor macro for each config 
section (Namhyung)
- rebased on current acme/perf/core

v5:
- rebased on current acme/perf/core

v4:
- rename 'fb_ground' to 'fore_back_colors' (Namhyung)
- add struct default_config_section
- split first patch[PATCH 1/7] as two
- remove perf_default_config_init() at perf.c
- rebased on current acme/perf/core

v3:
- remove default config arrays for the rest sections except 'colors' and 
'annotate'
- use combined {fore, back}ground colors instead of each two color
- introduce perf_default_config_init() that call all default_*_config_init()
  for each config section

v2:
- rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' (Arnaldo)
- change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
- use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)

Taeung Song (7):
  perf config: Introduce default_config_section and default_config_item
for default config key-value pairs
  perf config: Add macros assigning key-value pairs to
default_config_item
  perf config: Add default section and item arrays for 'colors' config
  perf config: Use combined {fore,back}ground colors value instead of
each two color
  perf config: Initialize ui_browser__colorsets with default config
items
  perf config: Add default section and item arrays for 'annotate' config
  perf config: Initialize annotate_browser__opts with default config
items

 tools/perf/ui/browser.c   | 64 +--
 tools/perf/ui/browsers/annotate.c | 16 ++--
 tools/perf/util/config.c  | 26 +
 tools/perf/util/config.h  | 80 +++
 4 files changed, 154 insertions(+), 32 deletions(-)

-- 
2.7.4

Re: [PATCH] RDS: Simplify code

[Leon Romanovsky]

On Mon, Sep 05, 2016 at 06:38:21AM +0200, Christophe JAILLET wrote:
> Le 04/09/2016 à 20:23, Leon Romanovsky a écrit :
> >On Sun, Sep 04, 2016 at 05:57:20PM +0200, Christophe JAILLET wrote:
> >>Le 04/09/2016 à 14:20, Leon Romanovsky a écrit :
> >>>On Sat, Sep 03, 2016 at 07:33:29AM +0200, Christophe JAILLET wrote:
> Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
> 'list_splice_init'.
> >>>It is not 100% accurate
> >>>
> >>>list_splice(y, z)
> >>>INIT_LIST_HEAD(y)
> >>>
> >>>==>
> >>>
> >>>if (!list_empty(y))
> >>>  __list_splice(y, z, z>next);
> >>>INIT_LIST_HEAD(y)
> >>>
> >>>and not
> >>>
> >>>if (!list_empty(y)) {
> >>>  __list_splice(y, z, z>next);
> >>>  INIT_LIST_HEAD(y)
> >>>}
> >>>
> >>>as list_splice_init will do.
> >>>
> >>You are right but if you dig further you will see that calling
> >>INIT_LIST_HEAD on an empty list is a no-op (AFAIK).
> >>And if this list was not already correctly initialized, then you would have
> >>some other troubles.
> >Thank you for the suggestion,
> >It looks like the code after that can be skipped in case of loop_conns
> >list is empty, the tmp_list will be empty too.
> >
> >174 list_for_each_entry_safe(lc, _lc, _list, loop_node) {
> >175 WARN_ON(lc->conn->c_passive);
> >176 rds_conn_destroy(lc->conn);
> >177 }
> Yes, but this would require some more code and test. This function doesn't
> seem to be in a hot path, so I'm not sure that the added complexity would
> worth it.
> It would require a new 'list_empty()' test and some code rearrangement.
>
> I suppose that testing for emptiness at the beginning or going through a
> list_for_each_entry_safe on a empty list (which will exit immediately and do
> nothing) is more or less the same in term of speed. So keep the code simple
> and readable.

I would expect one list_empty check at the beginning and return
immediately, but anyway it doesn't matter.

>
> CJ
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] pwm: twl: Reliably disable TWL6030 PWMs

[Thierry Reding]

On Tue, Mar 29, 2016 at 08:55:45PM +0200, Paul Kocialkowski wrote:
> The current TWL6030 code for the TWL PWM driver does not reliably disable the
> PWM output, as tested with LEDs. The previous commit to that driver introduced
> that regression.
> 
> However, it does make sense to disable the PWM clock after resetting the PWM,
> but for some obscure reason, doing it all at once simply doesn't work.
> 
> The TWL6030 datasheet mentions that PWMs have to be disabled in two distinct
> steps. However, clearing the clock enable bit in a second step (after issuing 
> a
> reset first) does not work.
> 
> The only approach that works is the one that was in place before the previous
> commit to the driver. It consists in enabling the PWM clock after issuing a
> reset. This is what TI kernel trees and production code seem to be using.
> 
> However, adding an extra step to disable the PWM clock seems to work reliably,
> despite looking quite odd.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/pwm/pwm-twl.c | 16 
>  1 file changed, 16 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] RDS: Simplify code

[Leon Romanovsky]

On Mon, Sep 05, 2016 at 06:38:21AM +0200, Christophe JAILLET wrote:
> Le 04/09/2016 à 20:23, Leon Romanovsky a écrit :
> >On Sun, Sep 04, 2016 at 05:57:20PM +0200, Christophe JAILLET wrote:
> >>Le 04/09/2016 à 14:20, Leon Romanovsky a écrit :
> >>>On Sat, Sep 03, 2016 at 07:33:29AM +0200, Christophe JAILLET wrote:
> Calling 'list_splice' followed by 'INIT_LIST_HEAD' is equivalent to
> 'list_splice_init'.
> >>>It is not 100% accurate
> >>>
> >>>list_splice(y, z)
> >>>INIT_LIST_HEAD(y)
> >>>
> >>>==>
> >>>
> >>>if (!list_empty(y))
> >>>  __list_splice(y, z, z>next);
> >>>INIT_LIST_HEAD(y)
> >>>
> >>>and not
> >>>
> >>>if (!list_empty(y)) {
> >>>  __list_splice(y, z, z>next);
> >>>  INIT_LIST_HEAD(y)
> >>>}
> >>>
> >>>as list_splice_init will do.
> >>>
> >>You are right but if you dig further you will see that calling
> >>INIT_LIST_HEAD on an empty list is a no-op (AFAIK).
> >>And if this list was not already correctly initialized, then you would have
> >>some other troubles.
> >Thank you for the suggestion,
> >It looks like the code after that can be skipped in case of loop_conns
> >list is empty, the tmp_list will be empty too.
> >
> >174 list_for_each_entry_safe(lc, _lc, _list, loop_node) {
> >175 WARN_ON(lc->conn->c_passive);
> >176 rds_conn_destroy(lc->conn);
> >177 }
> Yes, but this would require some more code and test. This function doesn't
> seem to be in a hot path, so I'm not sure that the added complexity would
> worth it.
> It would require a new 'list_empty()' test and some code rearrangement.
>
> I suppose that testing for emptiness at the beginning or going through a
> list_for_each_entry_safe on a empty list (which will exit immediately and do
> nothing) is more or less the same in term of speed. So keep the code simple
> and readable.

I would expect one list_empty check at the beginning and return
immediately, but anyway it doesn't matter.

>
> CJ
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] pwm: twl: Reliably disable TWL6030 PWMs

[Thierry Reding]

On Tue, Mar 29, 2016 at 08:55:45PM +0200, Paul Kocialkowski wrote:
> The current TWL6030 code for the TWL PWM driver does not reliably disable the
> PWM output, as tested with LEDs. The previous commit to that driver introduced
> that regression.
> 
> However, it does make sense to disable the PWM clock after resetting the PWM,
> but for some obscure reason, doing it all at once simply doesn't work.
> 
> The TWL6030 datasheet mentions that PWMs have to be disabled in two distinct
> steps. However, clearing the clock enable bit in a second step (after issuing 
> a
> reset first) does not work.
> 
> The only approach that works is the one that was in place before the previous
> commit to the driver. It consists in enabling the PWM clock after issuing a
> reset. This is what TI kernel trees and production code seem to be using.
> 
> However, adding an extra step to disable the PWM clock seems to work reliably,
> despite looking quite odd.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/pwm/pwm-twl.c | 16 
>  1 file changed, 16 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Hui Zhu]

On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim  wrote:
> On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
>> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
>>  wrote:
>> > Hello,
>> >
>> > On (08/22/16 16:25), Hui Zhu wrote:
>> >>
>> >> Current ZRAM just can store all pages even if the compression rate
>> >> of a page is really low.  So the compression rate of ZRAM is out of
>> >> control when it is running.
>> >> In my part, I did some test and record with ZRAM.  The compression rate
>> >> is about 40%.
>> >>
>> >> This series of patches make ZRAM can just store the page that the
>> >> compressed size is smaller than a value.
>> >> With these patches, I set the value to 2048 and did the same test with
>> >> before.  The compression rate is about 20%.  The times of lowmemorykiller
>> >> also decreased.
>> >
>> > I haven't looked at the patches in details yet. can you educate me a bit?
>> > is your test stable? why the number of lowmemorykill-s has decreased?
>> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
>> >
>> > suppose you have X pages that result in bad compression size (from zram
>> > point of view). zram stores such pages uncompressed, IOW we have no memory
>> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
>> > don't try to store those pages in zsmalloc, but keep them as unevictable.
>> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
>> > improve LMK?
>>
>> No, zram will not save this page uncompressed with these patches.  It
>> will set it as non-swap and kick back to shrink_page_list.
>> Shrink_page_list will remove this page from swapcache and kick it to
>> unevictable list.
>> Then this page will not be swaped before it get write.
>> That is why most of code are around vmscan.c.
>
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
>
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?
>
> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.
> Hui, is this scenario right for your case?
>

That is one reason.  But it is not the principal one.

Another reason is when swap is running to put page to zram, what the
system wants is to get memory.
Then the deal is system spends cpu time and memory to get memory. If
the zram just access the high compression rate pages, system can get
more memory with the same amount of memory. It will pull system from
low memory status earlier. (Maybe more cpu time, because the
compression rate checks. But maybe less, because fewer pages need to
digress. That is the interesting part. :)
I think that is why lmk times decrease.

And yes, all of this depends on the number of high compression rate
pages. So you cannot just set a non_swap limit to the system and get
everything. You need to do a lot of test around it to make sure the
non_swap limit is good for your system.

And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
special list will make cpu too busy sometimes.
I did some tests before I kick page to a special list. The shrink task
will be moved around, around and around because low compression rate
pages just moved from one list to another a lot of times, again, again
and again.
And all this low compression rate pages always stay together.

Thanks,
Hui


> Thanks.

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Hui Zhu]

On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim  wrote:
> On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
>> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
>>  wrote:
>> > Hello,
>> >
>> > On (08/22/16 16:25), Hui Zhu wrote:
>> >>
>> >> Current ZRAM just can store all pages even if the compression rate
>> >> of a page is really low.  So the compression rate of ZRAM is out of
>> >> control when it is running.
>> >> In my part, I did some test and record with ZRAM.  The compression rate
>> >> is about 40%.
>> >>
>> >> This series of patches make ZRAM can just store the page that the
>> >> compressed size is smaller than a value.
>> >> With these patches, I set the value to 2048 and did the same test with
>> >> before.  The compression rate is about 20%.  The times of lowmemorykiller
>> >> also decreased.
>> >
>> > I haven't looked at the patches in details yet. can you educate me a bit?
>> > is your test stable? why the number of lowmemorykill-s has decreased?
>> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
>> >
>> > suppose you have X pages that result in bad compression size (from zram
>> > point of view). zram stores such pages uncompressed, IOW we have no memory
>> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
>> > don't try to store those pages in zsmalloc, but keep them as unevictable.
>> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
>> > improve LMK?
>>
>> No, zram will not save this page uncompressed with these patches.  It
>> will set it as non-swap and kick back to shrink_page_list.
>> Shrink_page_list will remove this page from swapcache and kick it to
>> unevictable list.
>> Then this page will not be swaped before it get write.
>> That is why most of code are around vmscan.c.
>
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
>
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?
>
> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.
> Hui, is this scenario right for your case?
>

That is one reason.  But it is not the principal one.

Another reason is when swap is running to put page to zram, what the
system wants is to get memory.
Then the deal is system spends cpu time and memory to get memory. If
the zram just access the high compression rate pages, system can get
more memory with the same amount of memory. It will pull system from
low memory status earlier. (Maybe more cpu time, because the
compression rate checks. But maybe less, because fewer pages need to
digress. That is the interesting part. :)
I think that is why lmk times decrease.

And yes, all of this depends on the number of high compression rate
pages. So you cannot just set a non_swap limit to the system and get
everything. You need to do a lot of test around it to make sure the
non_swap limit is good for your system.

And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
special list will make cpu too busy sometimes.
I did some tests before I kick page to a special list. The shrink task
will be moved around, around and around because low compression rate
pages just moved from one list to another a lot of times, again, again
and again.
And all this low compression rate pages always stay together.

Thanks,
Hui


> Thanks.

[PATCH v10 1/5] Documentation: bindings: add dt documentation for dfi controller

[Lin Huang]

This patch adds the documentation for rockchip dfi devfreq-event driver.

Signed-off-by: Lin Huang 
Acked-by: Chanwoo Choi 
---
Changes in v10:
- None

Changes in v9:
- reorder compatible and reg

Changes in v8:
- delete a unuse blank line

Changes in v7:
- None

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- None 

Changes in v1:
- None

 .../bindings/devfreq/event/rockchip-dfi.txt   | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt

diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
new file mode 100644
index 000..f223313
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
@@ -0,0 +1,19 @@
+
+* Rockchip rk3399 DFI device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dfi".
+- reg: physical base address of each DFI and length of memory mapped region
+- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
+- clocks: phandles for clock specified in "clock-names" property
+- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
+
+Example:
+   dfi: dfi@0xff63 {
+   compatible = "rockchip,rk3399-dfi";
+   reg = <0x00 0xff63 0x00 0x4000>;
+   rockchip,pmu = <>;
+   clocks = < PCLK_DDR_MON>;
+   clock-names = "pclk_ddr_mon";
+   status = "disabled";
+   };
-- 
2.6.6

[PATCH v10 4/5] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Lin Huang]

base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.

Signed-off-by: Lin Huang 
Signed-off-by: MyngJoo Ham 
Reviewed-by: Chanwoo Choi 
---
Changes in v10:
- None

Changes in v9:
- None

Changes in v8:
- None

Changes in v8:
- do not use ddr_timing node, get ddr timing directly

Changes in v7:
- remove a blank line

Changes in v6:
- fix some nit suggest by Chanwoo Choi

Changes in v5:
- improve dmc driver suggest by Chanwoo Choi

Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order

Changes in v3:
- operate dram setting through sip call
- imporve set rate flow

Changes in v2:
- None

Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()

 drivers/devfreq/Kconfig  |  11 +
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/rk3399_dmc.c | 480 +++
 3 files changed, 492 insertions(+)
 create mode 100644 drivers/devfreq/rk3399_dmc.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..e848121 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -100,6 +100,17 @@ config ARM_TEGRA_DEVFREQ
  It reads ACTMON counters of memory controllers and adjusts the
  operating frequencies and voltages with OPP support.
 
+config ARM_RK3399_DMC_DEVFREQ
+   tristate "ARM RK3399 DMC DEVFREQ Driver"
+   depends on ARCH_ROCKCHIP
+   select DEVFREQ_EVENT_ROCKCHIP_DFI
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select PM_OPP
+   help
+  This adds the DEVFREQ driver for the RK3399 DMC(Dynamic Memory 
Controller).
+  It sets the frequency for the memory controller and reads the usage 
counts
+  from hardware.
+
 source "drivers/devfreq/event/Kconfig"
 
 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..fbff40a 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o
 
 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)   += rk3399_dmc.o
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
 
 # DEVFREQ Event Drivers
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
new file mode 100644
index 000..54d65f2
--- /dev/null
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -0,0 +1,480 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dram_timing {
+   unsigned int ddr3_speed_bin;
+   unsigned int pd_idle;
+   unsigned int sr_idle;
+   unsigned int sr_mc_gate_idle;
+   unsigned int srpd_lite_idle;
+   unsigned int standby_idle;
+   unsigned int auto_pd_dis_freq;
+   unsigned int dram_dll_dis_freq;
+   unsigned int phy_dll_dis_freq;
+   unsigned int ddr3_odt_dis_freq;
+   unsigned int ddr3_drv;
+   unsigned int ddr3_odt;
+   unsigned int phy_ddr3_ca_drv;
+   unsigned int phy_ddr3_dq_drv;
+   unsigned int phy_ddr3_odt;
+   unsigned int lpddr3_odt_dis_freq;
+   unsigned int lpddr3_drv;
+   unsigned int lpddr3_odt;
+   unsigned int phy_lpddr3_ca_drv;
+   unsigned int phy_lpddr3_dq_drv;
+   unsigned int phy_lpddr3_odt;
+   unsigned int lpddr4_odt_dis_freq;
+   unsigned int lpddr4_drv;
+   unsigned int lpddr4_dq_odt;
+   unsigned int lpddr4_ca_odt;
+   unsigned int phy_lpddr4_ca_drv;
+   unsigned int phy_lpddr4_ck_cs_drv;
+   unsigned int phy_lpddr4_dq_drv;
+   unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+   struct device *dev;
+   struct devfreq *devfreq;
+   struct devfreq_simple_ondemand_data ondemand_data;
+   struct clk *dmc_clk;
+   struct devfreq_event_dev *edev;
+   struct mutex lock;
+   struct dram_timing timing;
+
+   /*
+* DDR Converser of Frequency (DCF) is used to implement DDR frequency
+* conversion without the participation of CPU, we will implement and
+* 

[PATCH v10 3/5] Documentation: bindings: add dt documentation for rk3399 dmc

[Lin Huang]

This patch adds the documentation for rockchip rk3399 dmc driver.

Signed-off-by: Lin Huang 
Reviewed-by: Chanwoo Choi 
---
Changes in v10:
- add rockchip prefix in property describe

Changes in v9:
- add ddr timing property to node

Changes in v8:
- add ddr timing properties

Changes in v7:
- None

Changes in v6:
-Add more detail in Documentation

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None
 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 202 +
 1 file changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt

diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
new file mode 100644
index 000..84660a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
@@ -0,0 +1,210 @@
+* Rockchip rk3399 DMC(Dynamic Memory Controller) device
+
+Required properties:
+- compatible:   Must be "rockchip,rk3399-dmc".
+- devfreq-events:   Node to get DDR loading, Refer to
+Documentation/devicetree/bindings/devfreq/
+rockchip-dfi.txt
+- interrupts:   The interrupt number to the CPU. The interrupt
+specifier format depends on the interrupt controller.
+It should be DCF interrupts, when DDR dvfs finish,
+it will happen.
+- clocks:   Phandles for clock specified in "clock-names" property
+- clock-names : The name of clock used by the DFI, must be
+"pclk_ddr_mon";
+- operating-points-v2:  Refer to 
Documentation/devicetree/bindings/power/opp.txt
+for details.
+- center-supply:DMC supply node.
+- status:   Marks the node enabled/disabled.
+
+Following properties are ddr timing:
+
+- rockchip,dram_speed_bin :  Value reference 
include/dt-bindings/clock/ddr.h,
+ it select ddr3 cl-trp-trcd type, default value
+ "DDR3_DEFAULT".it must selected according to
+ "Speed Bin" in ddr3 datasheet, DO NOT use
+ smaller "Speed Bin" than ddr3 exactly is.
+
+- rockchip,pd_idle : Config the PD_IDLE value, defined the 
power-down
+ idle period, memories are places into 
power-down
+ mode if bus is idle for PD_IDLE DFI clocks.
+
+- rockchip,sr_idle : Configure the SR_IDLE value, defined the
+ selfrefresh idle period, memories are places
+ into self-refresh mode if bus is idle for
+ SR_IDLE*1024 DFI clocks (DFI clocks freq is
+ half of dram's clocks), defaule value is "0".
+
+- rockchip,sr_mc_gate_idle : Defined the self-refresh with memory and
+ controller clock gating idle period, memories
+ are places into self-refresh mode and memory
+ controller clock arg gating if bus is idle for
+ sr_mc_gate_idle*1024 DFI clocks.
+
+- rockchip,srpd_lite_idle :  Defined the self-refresh power down idle
+ period, memories are places into self-refresh
+ power down mode if bus is idle for
+ srpd_lite_idle*1024 DFI clocks. This parameter
+ is for LPDDR4 only.
+
+- rockchip,standby_idle :Defined the standby idle period, memories are
+ places into self-refresh than controller, pi,
+ phy and dram clock will gating if bus is idle
+ for standby_idle * DFI clocks.
+
+- rockchip,dram_dll_disb_freq :  It's defined the DDR3 dll bypass frequency in
+ MHz, when ddr freq less than 
DRAM_DLL_DISB_FREQ,
+ ddr3 dll will bypssed note: if dll was 
bypassed,
+ the odt also stop working.
+
+- rockchip,phy_dll_disb_freq :   Defined the PHY dll bypass frequency in
+ MHz (Mega Hz), when ddr freq less than
+ DRAM_DLL_DISB_FREQ, phy dll will bypssed.
+ note: phy dll and phy odt are independent.
+
+- rockchip,ddr3_odt_disb_freq :  When dram type is DDR3, this parameter defined
+ the odt disable frequency in MHz (Mega Hz),
+ when ddr frequency less then 
ddr3_odt_disb_freq,
+ the odt on dram 

[PATCH v10 1/5] Documentation: bindings: add dt documentation for dfi controller

[Lin Huang]

This patch adds the documentation for rockchip dfi devfreq-event driver.

Signed-off-by: Lin Huang 
Acked-by: Chanwoo Choi 
---
Changes in v10:
- None

Changes in v9:
- reorder compatible and reg

Changes in v8:
- delete a unuse blank line

Changes in v7:
- None

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- None 

Changes in v1:
- None

 .../bindings/devfreq/event/rockchip-dfi.txt   | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt

diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
new file mode 100644
index 000..f223313
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
@@ -0,0 +1,19 @@
+
+* Rockchip rk3399 DFI device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dfi".
+- reg: physical base address of each DFI and length of memory mapped region
+- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
+- clocks: phandles for clock specified in "clock-names" property
+- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
+
+Example:
+   dfi: dfi@0xff63 {
+   compatible = "rockchip,rk3399-dfi";
+   reg = <0x00 0xff63 0x00 0x4000>;
+   rockchip,pmu = <>;
+   clocks = < PCLK_DDR_MON>;
+   clock-names = "pclk_ddr_mon";
+   status = "disabled";
+   };
-- 
2.6.6

[PATCH v10 4/5] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Lin Huang]

base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.

Signed-off-by: Lin Huang 
Signed-off-by: MyngJoo Ham 
Reviewed-by: Chanwoo Choi 
---
Changes in v10:
- None

Changes in v9:
- None

Changes in v8:
- None

Changes in v8:
- do not use ddr_timing node, get ddr timing directly

Changes in v7:
- remove a blank line

Changes in v6:
- fix some nit suggest by Chanwoo Choi

Changes in v5:
- improve dmc driver suggest by Chanwoo Choi

Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order

Changes in v3:
- operate dram setting through sip call
- imporve set rate flow

Changes in v2:
- None

Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()

 drivers/devfreq/Kconfig  |  11 +
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/rk3399_dmc.c | 480 +++
 3 files changed, 492 insertions(+)
 create mode 100644 drivers/devfreq/rk3399_dmc.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..e848121 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -100,6 +100,17 @@ config ARM_TEGRA_DEVFREQ
  It reads ACTMON counters of memory controllers and adjusts the
  operating frequencies and voltages with OPP support.
 
+config ARM_RK3399_DMC_DEVFREQ
+   tristate "ARM RK3399 DMC DEVFREQ Driver"
+   depends on ARCH_ROCKCHIP
+   select DEVFREQ_EVENT_ROCKCHIP_DFI
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select PM_OPP
+   help
+  This adds the DEVFREQ driver for the RK3399 DMC(Dynamic Memory 
Controller).
+  It sets the frequency for the memory controller and reads the usage 
counts
+  from hardware.
+
 source "drivers/devfreq/event/Kconfig"
 
 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..fbff40a 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o
 
 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)   += rk3399_dmc.o
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
 
 # DEVFREQ Event Drivers
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
new file mode 100644
index 000..54d65f2
--- /dev/null
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -0,0 +1,480 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dram_timing {
+   unsigned int ddr3_speed_bin;
+   unsigned int pd_idle;
+   unsigned int sr_idle;
+   unsigned int sr_mc_gate_idle;
+   unsigned int srpd_lite_idle;
+   unsigned int standby_idle;
+   unsigned int auto_pd_dis_freq;
+   unsigned int dram_dll_dis_freq;
+   unsigned int phy_dll_dis_freq;
+   unsigned int ddr3_odt_dis_freq;
+   unsigned int ddr3_drv;
+   unsigned int ddr3_odt;
+   unsigned int phy_ddr3_ca_drv;
+   unsigned int phy_ddr3_dq_drv;
+   unsigned int phy_ddr3_odt;
+   unsigned int lpddr3_odt_dis_freq;
+   unsigned int lpddr3_drv;
+   unsigned int lpddr3_odt;
+   unsigned int phy_lpddr3_ca_drv;
+   unsigned int phy_lpddr3_dq_drv;
+   unsigned int phy_lpddr3_odt;
+   unsigned int lpddr4_odt_dis_freq;
+   unsigned int lpddr4_drv;
+   unsigned int lpddr4_dq_odt;
+   unsigned int lpddr4_ca_odt;
+   unsigned int phy_lpddr4_ca_drv;
+   unsigned int phy_lpddr4_ck_cs_drv;
+   unsigned int phy_lpddr4_dq_drv;
+   unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+   struct device *dev;
+   struct devfreq *devfreq;
+   struct devfreq_simple_ondemand_data ondemand_data;
+   struct clk *dmc_clk;
+   struct devfreq_event_dev *edev;
+   struct mutex lock;
+   struct dram_timing timing;
+
+   /*
+* DDR Converser of Frequency (DCF) is used to implement DDR frequency
+* conversion without the participation of CPU, we will implement and
+* control it in arm trust firmware.
+*/
+   wait_queue_head_t   

[PATCH v10 3/5] Documentation: bindings: add dt documentation for rk3399 dmc

[Lin Huang]

This patch adds the documentation for rockchip rk3399 dmc driver.

Signed-off-by: Lin Huang 
Reviewed-by: Chanwoo Choi 
---
Changes in v10:
- add rockchip prefix in property describe

Changes in v9:
- add ddr timing property to node

Changes in v8:
- add ddr timing properties

Changes in v7:
- None

Changes in v6:
-Add more detail in Documentation

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None
 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 202 +
 1 file changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt

diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
new file mode 100644
index 000..84660a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
@@ -0,0 +1,210 @@
+* Rockchip rk3399 DMC(Dynamic Memory Controller) device
+
+Required properties:
+- compatible:   Must be "rockchip,rk3399-dmc".
+- devfreq-events:   Node to get DDR loading, Refer to
+Documentation/devicetree/bindings/devfreq/
+rockchip-dfi.txt
+- interrupts:   The interrupt number to the CPU. The interrupt
+specifier format depends on the interrupt controller.
+It should be DCF interrupts, when DDR dvfs finish,
+it will happen.
+- clocks:   Phandles for clock specified in "clock-names" property
+- clock-names : The name of clock used by the DFI, must be
+"pclk_ddr_mon";
+- operating-points-v2:  Refer to 
Documentation/devicetree/bindings/power/opp.txt
+for details.
+- center-supply:DMC supply node.
+- status:   Marks the node enabled/disabled.
+
+Following properties are ddr timing:
+
+- rockchip,dram_speed_bin :  Value reference 
include/dt-bindings/clock/ddr.h,
+ it select ddr3 cl-trp-trcd type, default value
+ "DDR3_DEFAULT".it must selected according to
+ "Speed Bin" in ddr3 datasheet, DO NOT use
+ smaller "Speed Bin" than ddr3 exactly is.
+
+- rockchip,pd_idle : Config the PD_IDLE value, defined the 
power-down
+ idle period, memories are places into 
power-down
+ mode if bus is idle for PD_IDLE DFI clocks.
+
+- rockchip,sr_idle : Configure the SR_IDLE value, defined the
+ selfrefresh idle period, memories are places
+ into self-refresh mode if bus is idle for
+ SR_IDLE*1024 DFI clocks (DFI clocks freq is
+ half of dram's clocks), defaule value is "0".
+
+- rockchip,sr_mc_gate_idle : Defined the self-refresh with memory and
+ controller clock gating idle period, memories
+ are places into self-refresh mode and memory
+ controller clock arg gating if bus is idle for
+ sr_mc_gate_idle*1024 DFI clocks.
+
+- rockchip,srpd_lite_idle :  Defined the self-refresh power down idle
+ period, memories are places into self-refresh
+ power down mode if bus is idle for
+ srpd_lite_idle*1024 DFI clocks. This parameter
+ is for LPDDR4 only.
+
+- rockchip,standby_idle :Defined the standby idle period, memories are
+ places into self-refresh than controller, pi,
+ phy and dram clock will gating if bus is idle
+ for standby_idle * DFI clocks.
+
+- rockchip,dram_dll_disb_freq :  It's defined the DDR3 dll bypass frequency in
+ MHz, when ddr freq less than 
DRAM_DLL_DISB_FREQ,
+ ddr3 dll will bypssed note: if dll was 
bypassed,
+ the odt also stop working.
+
+- rockchip,phy_dll_disb_freq :   Defined the PHY dll bypass frequency in
+ MHz (Mega Hz), when ddr freq less than
+ DRAM_DLL_DISB_FREQ, phy dll will bypssed.
+ note: phy dll and phy odt are independent.
+
+- rockchip,ddr3_odt_disb_freq :  When dram type is DDR3, this parameter defined
+ the odt disable frequency in MHz (Mega Hz),
+ when ddr frequency less then 
ddr3_odt_disb_freq,
+ the odt on dram side and controller side are
+  

[PATCH v10 0/5] rk3399 support ddr frequency scaling

[Lin Huang]

rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:

 kernelbl31

monitor ddr load
|
|
get_target_rate
|
|   pass rate to bl31
clk_set_rate(ddr) ->run dcf flow
|   |
|   |
wait dcf interrupt<---trigger dcf interrupt
|
|
  return


Lin Huang (5):
  Documentation: bindings: add dt documentation for dfi controller
  PM / devfreq: event: support rockchip dfi controller
  Documentation: bindings: add dt documentation for rk3399 dmc
  PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
  drm/rockchip: Add dmc notifier in vop driver

Following patch:
clk: rockchip: add new clock-type for the ddrclk
clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
clk: rockchip: rk3399: add ddrc clock support
have applied to:
http://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/v4.9-clk/next


 .../bindings/devfreq/event/rockchip-dfi.txt|  19 +
 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 210 +
 drivers/devfreq/Kconfig|  11 +
 drivers/devfreq/Makefile   |   1 +
 drivers/devfreq/event/Kconfig  |   7 +
 drivers/devfreq/event/Makefile |   1 +
 drivers/devfreq/event/rockchip-dfi.c   | 256 +++
 drivers/devfreq/rk3399_dmc.c   | 480 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 116 +
 9 files changed, 1101 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c
 create mode 100644 drivers/devfreq/rk3399_dmc.c

-- 
2.6.6

[PATCH v10 0/5] rk3399 support ddr frequency scaling

[Lin Huang]

rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:

 kernelbl31

monitor ddr load
|
|
get_target_rate
|
|   pass rate to bl31
clk_set_rate(ddr) ->run dcf flow
|   |
|   |
wait dcf interrupt<---trigger dcf interrupt
|
|
  return


Lin Huang (5):
  Documentation: bindings: add dt documentation for dfi controller
  PM / devfreq: event: support rockchip dfi controller
  Documentation: bindings: add dt documentation for rk3399 dmc
  PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
  drm/rockchip: Add dmc notifier in vop driver

Following patch:
clk: rockchip: add new clock-type for the ddrclk
clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
clk: rockchip: rk3399: add ddrc clock support
have applied to:
http://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/v4.9-clk/next


 .../bindings/devfreq/event/rockchip-dfi.txt|  19 +
 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 210 +
 drivers/devfreq/Kconfig|  11 +
 drivers/devfreq/Makefile   |   1 +
 drivers/devfreq/event/Kconfig  |   7 +
 drivers/devfreq/event/Makefile |   1 +
 drivers/devfreq/event/rockchip-dfi.c   | 256 +++
 drivers/devfreq/rk3399_dmc.c   | 480 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 116 +
 9 files changed, 1101 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c
 create mode 100644 drivers/devfreq/rk3399_dmc.c

-- 
2.6.6

[PATCH v10 2/5] PM / devfreq: event: support rockchip dfi controller

[Lin Huang]

on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.

Signed-off-by: Lin Huang 
Signed-off-by: MyungJoo Ham 
Acked-by: Chanwoo Choi 
---
Changes in v10:
-None

Changes in v9:
-None

Changes in v8:
-None

Changes in v7:
-access need to *4 to get right DDR loading

Changes in v6:
-None

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 drivers/devfreq/event/Kconfig|   7 +
 drivers/devfreq/event/Makefile   |   1 +
 drivers/devfreq/event/rockchip-dfi.c | 256 +++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c

diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..20d82c2 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
  (Platform Performance Monitoring Unit) counters to estimate the
  utilization of each module.
 
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+   tristate "ROCKCHIP DFI DEVFREQ event Driver"
+   depends on ARCH_ROCKCHIP
+   help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
 endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@
 
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c 
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..43fcc5a
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,256 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RK3399_DMC_NUM_CH  2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN  (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN  (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define SOFTWARE_DIS   (0x1 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM   0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM  0x2c
+#define DDRMON_CH1_COUNT_NUM   0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM  0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT  13
+#define DDRTYPE_MASK   7
+
+enum {
+   DDR3 = 3,
+   LPDDR3 = 6,
+   LPDDR4 = 7,
+   UNUSED = 0xFF
+};
+
+struct dmc_usage {
+   u32 access;
+   u32 total;
+};
+
+/*
+ * The dfi controller can monitor DDR load. It has an upper and lower threshold
+ * for the operating points. Whenever the usage leaves these bounds an event is
+ * generated to indicate the DDR frequency should be changed.
+ */
+struct rockchip_dfi {
+   struct devfreq_event_dev *edev;
+   struct devfreq_event_desc *desc;
+   struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *regmap_pmu;
+   struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+   u32 ddr_type;
+
+   /* get ddr type */
+   regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
+   ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+   /* clear DDRMON_CTRL setting */
+   writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+   /* set ddr type to dfi */
+   if (ddr_type == LPDDR3)
+   writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+   else if (ddr_type == LPDDR4)
+   writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+   /* enable count, use software mode */
+   writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+   

[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver

[Lin Huang]

when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not work, dcf can do ddr frequency
any time. So when do ddr frequency scaling, you disabled or enable
vop, there may two bad thing happen: 1, the panel flicker(when vop from
disable status change to enable). 2, kernel hang (when vop from enable
status change to disable, dcf need to read vblank status, but if you disable
vop clock, it can not get the status, it will lead soc dead) So we need
register to devfreq notifier, and we can get the dmc status. Also, when
there have two vop enabled, we need to disable dmc, since dcf only base
on one vop vblank time, so the other panel will flicker when do ddr
frequency scaling.

Signed-off-by: Lin Huang 
Reviewed-by: Chanwoo Choi 
---
Changes in v10:
- None

Changes in v9:
- None

Changes in v8:
- None

Changes in v7:
- None

Changes in v6:
- fix a build error

Changes in v5:
- improve some nits

Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc

Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish

Changes in v2:
- None

Changes in v1:
- use wait_event instead usleep

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index efbc41a..a73f3aa 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +120,13 @@ struct vop {
 
const struct vop_data *data;
 
+   struct devfreq *devfreq;
+   struct devfreq_event_dev *devfreq_event_dev;
+   struct notifier_block dmc_nb;
+   int dmc_in_process;
+   int vop_switch_status;
+   wait_queue_head_t wait_dmc_queue;
+   wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
 
@@ -428,11 +437,47 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
*vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+   struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+   if (event == DEVFREQ_PRECHANGE) {
+   /*
+* check if vop in enable or disable process,
+* if yes, wait until it finishes, use 200ms as
+* timeout.
+*/
+   if (!wait_event_timeout(vop->wait_vop_switch_queue,
+   !vop->vop_switch_status, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+   vop->dmc_in_process = 1;
+   } else if (event == DEVFREQ_POSTCHANGE) {
+   vop->dmc_in_process = 0;
+   wake_up(>wait_dmc_queue);
+   }
+
+   return NOTIFY_OK;
+}
+
 static int vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
+   int num_enabled_crtc = 0;
int ret;
 
+   /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 200ms as timeout time.
+*/
+   if (!wait_event_timeout(vop->wait_dmc_queue,
+   !vop->dmc_in_process, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+   vop->vop_switch_status = 1;
+
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
@@ -479,6 +524,21 @@ static int vop_enable(struct drm_crtc *crtc)
 
drm_crtc_vblank_on(crtc);
 
+   vop->vop_switch_status = 0;
+   wake_up(>wait_vop_switch_queue);
+
+   /* check how many VOPs in use now */
+   drm_for_each_crtc(crtc, vop->drm_dev) {
+   if (crtc->state->enable)
+   num_enabled_crtc++;
+   }
+
+   /* if enable two vop, need to disable dmc */
+   if ((num_enabled_crtc > 1) && vop->devfreq) {
+   if (vop->devfreq_event_dev)
+   devfreq_event_disable_edev(vop->devfreq_event_dev);
+   devfreq_suspend_device(vop->devfreq);
+   }
return 0;
 
 err_disable_aclk:
@@ -489,17 +549,31 @@ err_disable_hclk:
clk_disable(vop->hclk);
 err_put_pm_runtime:
pm_runtime_put_sync(vop->dev);
+   vop->vop_switch_status = 0;
+   

[PATCH v10 2/5] PM / devfreq: event: support rockchip dfi controller

[Lin Huang]

on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.

Signed-off-by: Lin Huang 
Signed-off-by: MyungJoo Ham 
Acked-by: Chanwoo Choi 
---
Changes in v10:
-None

Changes in v9:
-None

Changes in v8:
-None

Changes in v7:
-access need to *4 to get right DDR loading

Changes in v6:
-None

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 drivers/devfreq/event/Kconfig|   7 +
 drivers/devfreq/event/Makefile   |   1 +
 drivers/devfreq/event/rockchip-dfi.c | 256 +++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c

diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..20d82c2 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
  (Platform Performance Monitoring Unit) counters to estimate the
  utilization of each module.
 
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+   tristate "ROCKCHIP DFI DEVFREQ event Driver"
+   depends on ARCH_ROCKCHIP
+   help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
 endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@
 
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c 
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..43fcc5a
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,256 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RK3399_DMC_NUM_CH  2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN  (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN  (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define SOFTWARE_DIS   (0x1 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM   0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM  0x2c
+#define DDRMON_CH1_COUNT_NUM   0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM  0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT  13
+#define DDRTYPE_MASK   7
+
+enum {
+   DDR3 = 3,
+   LPDDR3 = 6,
+   LPDDR4 = 7,
+   UNUSED = 0xFF
+};
+
+struct dmc_usage {
+   u32 access;
+   u32 total;
+};
+
+/*
+ * The dfi controller can monitor DDR load. It has an upper and lower threshold
+ * for the operating points. Whenever the usage leaves these bounds an event is
+ * generated to indicate the DDR frequency should be changed.
+ */
+struct rockchip_dfi {
+   struct devfreq_event_dev *edev;
+   struct devfreq_event_desc *desc;
+   struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *regmap_pmu;
+   struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+   u32 ddr_type;
+
+   /* get ddr type */
+   regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
+   ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+   /* clear DDRMON_CTRL setting */
+   writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+   /* set ddr type to dfi */
+   if (ddr_type == LPDDR3)
+   writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+   else if (ddr_type == LPDDR4)
+   writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+   /* enable count, use software mode */
+   writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs 

[PATCH v10 5/5] drm/rockchip: Add dmc notifier in vop driver

[Lin Huang]

when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not work, dcf can do ddr frequency
any time. So when do ddr frequency scaling, you disabled or enable
vop, there may two bad thing happen: 1, the panel flicker(when vop from
disable status change to enable). 2, kernel hang (when vop from enable
status change to disable, dcf need to read vblank status, but if you disable
vop clock, it can not get the status, it will lead soc dead) So we need
register to devfreq notifier, and we can get the dmc status. Also, when
there have two vop enabled, we need to disable dmc, since dcf only base
on one vop vblank time, so the other panel will flicker when do ddr
frequency scaling.

Signed-off-by: Lin Huang 
Reviewed-by: Chanwoo Choi 
---
Changes in v10:
- None

Changes in v9:
- None

Changes in v8:
- None

Changes in v7:
- None

Changes in v6:
- fix a build error

Changes in v5:
- improve some nits

Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc

Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish

Changes in v2:
- None

Changes in v1:
- use wait_event instead usleep

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index efbc41a..a73f3aa 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +120,13 @@ struct vop {
 
const struct vop_data *data;
 
+   struct devfreq *devfreq;
+   struct devfreq_event_dev *devfreq_event_dev;
+   struct notifier_block dmc_nb;
+   int dmc_in_process;
+   int vop_switch_status;
+   wait_queue_head_t wait_dmc_queue;
+   wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
 
@@ -428,11 +437,47 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
*vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+   struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+   if (event == DEVFREQ_PRECHANGE) {
+   /*
+* check if vop in enable or disable process,
+* if yes, wait until it finishes, use 200ms as
+* timeout.
+*/
+   if (!wait_event_timeout(vop->wait_vop_switch_queue,
+   !vop->vop_switch_status, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+   vop->dmc_in_process = 1;
+   } else if (event == DEVFREQ_POSTCHANGE) {
+   vop->dmc_in_process = 0;
+   wake_up(>wait_dmc_queue);
+   }
+
+   return NOTIFY_OK;
+}
+
 static int vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
+   int num_enabled_crtc = 0;
int ret;
 
+   /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 200ms as timeout time.
+*/
+   if (!wait_event_timeout(vop->wait_dmc_queue,
+   !vop->dmc_in_process, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+   vop->vop_switch_status = 1;
+
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
@@ -479,6 +524,21 @@ static int vop_enable(struct drm_crtc *crtc)
 
drm_crtc_vblank_on(crtc);
 
+   vop->vop_switch_status = 0;
+   wake_up(>wait_vop_switch_queue);
+
+   /* check how many VOPs in use now */
+   drm_for_each_crtc(crtc, vop->drm_dev) {
+   if (crtc->state->enable)
+   num_enabled_crtc++;
+   }
+
+   /* if enable two vop, need to disable dmc */
+   if ((num_enabled_crtc > 1) && vop->devfreq) {
+   if (vop->devfreq_event_dev)
+   devfreq_event_disable_edev(vop->devfreq_event_dev);
+   devfreq_suspend_device(vop->devfreq);
+   }
return 0;
 
 err_disable_aclk:
@@ -489,17 +549,31 @@ err_disable_hclk:
clk_disable(vop->hclk);
 err_put_pm_runtime:
pm_runtime_put_sync(vop->dev);
+   vop->vop_switch_status = 0;
+   wake_up(>wait_vop_switch_queue);
return ret;
 }
 
 static 

[PATCH] ubifs: compress lines for immediate return

[Heiko Schocher]

fix the following code:

-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;

From: Masahiro Yamada 
posted on the U-Boot mailinglist.

Signed-off-by: Heiko Schocher 
---

 fs/ubifs/budget.c | 7 ++-
 fs/ubifs/gc.c | 6 ++
 fs/ubifs/lpt_commit.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index 11a11b3..48d6851 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -77,7 +77,7 @@ static void shrink_liability(struct ubifs_info *c, int 
nr_to_write)
  */
 static int run_gc(struct ubifs_info *c)
 {
-   int err, lnum;
+   int lnum;
 
/* Make some free space by garbage-collecting dirty space */
down_read(>commit_sem);
@@ -88,10 +88,7 @@ static int run_gc(struct ubifs_info *c)
 
/* GC freed one LEB, return it to lprops */
dbg_budg("GC freed LEB %d", lnum);
-   err = ubifs_return_leb(c, lnum);
-   if (err)
-   return err;
-   return 0;
+   return = ubifs_return_leb(c, lnum);
 }
 
 /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
 }
 
 /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
alen = ALIGN(offs, c->min_io_size);
upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);
 
 no_space:
ubifs_err(c, "LPT out of space at LEB %d:%d needing %d, done_ltab %d, 
done_lsave %d",
-- 
2.5.5

[PATCH] ubifs: compress lines for immediate return

[Heiko Schocher]

fix the following code:

-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;

From: Masahiro Yamada 
posted on the U-Boot mailinglist.

Signed-off-by: Heiko Schocher 
---

 fs/ubifs/budget.c | 7 ++-
 fs/ubifs/gc.c | 6 ++
 fs/ubifs/lpt_commit.c | 5 +
 3 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index 11a11b3..48d6851 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -77,7 +77,7 @@ static void shrink_liability(struct ubifs_info *c, int 
nr_to_write)
  */
 static int run_gc(struct ubifs_info *c)
 {
-   int err, lnum;
+   int lnum;
 
/* Make some free space by garbage-collecting dirty space */
down_read(>commit_sem);
@@ -88,10 +88,7 @@ static int run_gc(struct ubifs_info *c)
 
/* GC freed one LEB, return it to lprops */
dbg_budg("GC freed LEB %d", lnum);
-   err = ubifs_return_leb(c, lnum);
-   if (err)
-   return err;
-   return 0;
+   return = ubifs_return_leb(c, lnum);
 }
 
 /**
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 821b348..88cd61d 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -297,10 +297,8 @@ static int sort_nodes(struct ubifs_info *c, struct 
ubifs_scan_leb *sleb,
err = dbg_check_data_nodes_order(c, >nodes);
if (err)
return err;
-   err = dbg_check_nondata_nodes_order(c, nondata);
-   if (err)
-   return err;
-   return 0;
+
+   return dbg_check_nondata_nodes_order(c, nondata);
 }
 
 /**
diff --git a/fs/ubifs/lpt_commit.c b/fs/ubifs/lpt_commit.c
index ce89bdc..79a8e96 100644
--- a/fs/ubifs/lpt_commit.c
+++ b/fs/ubifs/lpt_commit.c
@@ -313,10 +313,7 @@ static int layout_cnodes(struct ubifs_info *c)
alen = ALIGN(offs, c->min_io_size);
upd_ltab(c, lnum, c->leb_size - alen, alen - offs);
dbg_chk_lpt_sz(c, 4, alen - offs);
-   err = dbg_chk_lpt_sz(c, 3, alen);
-   if (err)
-   return err;
-   return 0;
+   return dbg_chk_lpt_sz(c, 3, alen);
 
 no_space:
ubifs_err(c, "LPT out of space at LEB %d:%d needing %d, done_ltab %d, 
done_lsave %d",
-- 
2.5.5

linux-next: manual merge of the md tree with the s390 tree

[Stephen Rothwell]

Hi Shaohua,

Today's linux-next merge of the md tree got a conflict in:

  include/linux/raid/pq.h

between commit:

  f5b55fa1f81d ("RAID/s390: provide raid6 recovery optimization")

from the s390 tree and commit:

  a5e49b04af05 ("lib/raid6: Add AVX512 optimized recovery functions")

from the md tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/raid/pq.h
index 395a4c674168,1abd89584568..
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@@ -102,8 -102,10 +102,11 @@@ extern const struct raid6_calls raid6_a
  extern const struct raid6_calls raid6_avx2x1;
  extern const struct raid6_calls raid6_avx2x2;
  extern const struct raid6_calls raid6_avx2x4;
+ extern const struct raid6_calls raid6_avx512x1;
+ extern const struct raid6_calls raid6_avx512x2;
+ extern const struct raid6_calls raid6_avx512x4;
  extern const struct raid6_calls raid6_tilegx8;
 +extern const struct raid6_calls raid6_s390vx8;
  
  struct raid6_recov_calls {
void (*data2)(int, size_t, int, int, void **);
@@@ -116,7 -118,7 +119,8 @@@
  extern const struct raid6_recov_calls raid6_recov_intx1;
  extern const struct raid6_recov_calls raid6_recov_ssse3;
  extern const struct raid6_recov_calls raid6_recov_avx2;
+ extern const struct raid6_recov_calls raid6_recov_avx512;
 +extern const struct raid6_recov_calls raid6_recov_s390xc;
  
  extern const struct raid6_calls raid6_neonx1;
  extern const struct raid6_calls raid6_neonx2;

linux-next: manual merge of the md tree with the s390 tree

[Stephen Rothwell]

Hi Shaohua,

Today's linux-next merge of the md tree got a conflict in:

  include/linux/raid/pq.h

between commit:

  f5b55fa1f81d ("RAID/s390: provide raid6 recovery optimization")

from the s390 tree and commit:

  a5e49b04af05 ("lib/raid6: Add AVX512 optimized recovery functions")

from the md tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/raid/pq.h
index 395a4c674168,1abd89584568..
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@@ -102,8 -102,10 +102,11 @@@ extern const struct raid6_calls raid6_a
  extern const struct raid6_calls raid6_avx2x1;
  extern const struct raid6_calls raid6_avx2x2;
  extern const struct raid6_calls raid6_avx2x4;
+ extern const struct raid6_calls raid6_avx512x1;
+ extern const struct raid6_calls raid6_avx512x2;
+ extern const struct raid6_calls raid6_avx512x4;
  extern const struct raid6_calls raid6_tilegx8;
 +extern const struct raid6_calls raid6_s390vx8;
  
  struct raid6_recov_calls {
void (*data2)(int, size_t, int, int, void **);
@@@ -116,7 -118,7 +119,8 @@@
  extern const struct raid6_recov_calls raid6_recov_intx1;
  extern const struct raid6_recov_calls raid6_recov_ssse3;
  extern const struct raid6_recov_calls raid6_recov_avx2;
+ extern const struct raid6_recov_calls raid6_recov_avx512;
 +extern const struct raid6_recov_calls raid6_recov_s390xc;
  
  extern const struct raid6_calls raid6_neonx1;
  extern const struct raid6_calls raid6_neonx2;

[PATCH v3] ARM: dts: sun8i: Add dts file for the NanoPi NEO SBC

[James Pettigrew]

The NanoPi NEO is a minimal H3 based SBC. It comes with 256/512M RAM, a
micro SD slot, 10/100Mbit ethernet and a single USB-A port.

Signed-off-by: James Pettigrew 
---
Changes in v3:

Fixed syntax errors
---
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts  | 125 +
 3 files changed, 127 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..7b6bda3 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -98,6 +98,7 @@ ezchipEZchip Semiconductor
 fcsFairchild Semiconductor
 fireflyFirefly
 focaltech  FocalTech Systems Co.,Ltd
+friendlyarmGuangzhou FriendlyARM Computer Tech Co., Ltd
 fslFreescale Semiconductor
 ge General Electric Company
 geekbuying GeekBuying
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7dd4a07..a35f986 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -792,6 +792,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+   sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
sun8i-h3-orangepi-one.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
new file mode 100644
index 000..3d64caf
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -0,0 +1,125 @@
+/*
+ * Copyright (C) 2016 James Pettigrew 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO";
+   compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_opc>, <_r_opc>;
+
+   pwr {
+   label = "nanopi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+   default-state = "on";
+   };
+
+   status {
+   label = "nanopi:blue:status";
+   gpios = < 0 10 GPIO_ACTIVE_HIGH>; /* PA10 */
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>, <_cd_pin>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   

[PATCH v3] ARM: dts: sun8i: Add dts file for the NanoPi NEO SBC

[James Pettigrew]

The NanoPi NEO is a minimal H3 based SBC. It comes with 256/512M RAM, a
micro SD slot, 10/100Mbit ethernet and a single USB-A port.

Signed-off-by: James Pettigrew 
---
Changes in v3:

Fixed syntax errors
---
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts  | 125 +
 3 files changed, 127 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..7b6bda3 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -98,6 +98,7 @@ ezchipEZchip Semiconductor
 fcsFairchild Semiconductor
 fireflyFirefly
 focaltech  FocalTech Systems Co.,Ltd
+friendlyarmGuangzhou FriendlyARM Computer Tech Co., Ltd
 fslFreescale Semiconductor
 ge General Electric Company
 geekbuying GeekBuying
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7dd4a07..a35f986 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -792,6 +792,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+   sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
sun8i-h3-orangepi-one.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
new file mode 100644
index 000..3d64caf
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -0,0 +1,125 @@
+/*
+ * Copyright (C) 2016 James Pettigrew 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO";
+   compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_opc>, <_r_opc>;
+
+   pwr {
+   label = "nanopi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+   default-state = "on";
+   };
+
+   status {
+   label = "nanopi:blue:status";
+   gpios = < 0 10 GPIO_ACTIVE_HIGH>; /* PA10 */
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>, <_cd_pin>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   cd-inverted;
+   status = "okay";
+};
+

Re: [PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

[Naohiro Aota]

2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました:
> On 09/02/2016 03:46 AM, Naohiro Aota wrote:
> > 
> > Currently, btrfs_relocate_chunk() is removing relocated BG by
> > itself. But
> > the work can be done by btrfs_delete_unused_bgs() (and it's better
> > since it
> > trim the BG). Let's dedupe the code.
> > 
> > While btrfs_delete_unused_bgs() is already hitting the relocated
> > BG, it
> > skip the BG since the BG has "ro" flag set (to keep balancing BG
> > intact).
> > On the other hand, btrfs cannot drop "ro" flag here to prevent
> > additional
> > writes. So this patch make use of "removed" flag.
> > btrfs_delete_unused_bgs() now detect the flag to distinguish
> > whether a
> > read-only BG is relocating or not.
> > 
> 
> This seems racey to me.  We remove the last part of the block group,
> it ends up 
> on the unused_bgs_list, we process this list, see that removed isn't
> set and we 
> skip it, then later we set removed, but it's too late.  I think the
> right way is 
> to actually do a transaction, set ->removed, manually add it to the 
> unused_bgs_list if it's not already, then end the transaction.  This
> way we are 
> guaranteed to have the bg on the list when it is ready to be
> removed.  This is 
> my analysis after looking at it for 10 seconds after being awake for
> like 30 
> minutes so if I'm missing something let me know.  Thanks,

I don't think a race will happen. Since we are holding
delete_unused_bgs_mutex here, btrfs_delte_unused_bgs() checks ->removed
flag after we unlock the mutex i.e. we setup the flag properly. For a
case btrfs_delete_usused_bgs() checks the BG before we hold
delte_unused_bgs_mutex, then that BG is removed by it (if it's empty)
and btrfs_relocate_chunk() should never see it.

Regards,
Naohiro

Re: [PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

[Naohiro Aota]

2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました:
> On 09/02/2016 03:46 AM, Naohiro Aota wrote:
> > 
> > Currently, btrfs_relocate_chunk() is removing relocated BG by
> > itself. But
> > the work can be done by btrfs_delete_unused_bgs() (and it's better
> > since it
> > trim the BG). Let's dedupe the code.
> > 
> > While btrfs_delete_unused_bgs() is already hitting the relocated
> > BG, it
> > skip the BG since the BG has "ro" flag set (to keep balancing BG
> > intact).
> > On the other hand, btrfs cannot drop "ro" flag here to prevent
> > additional
> > writes. So this patch make use of "removed" flag.
> > btrfs_delete_unused_bgs() now detect the flag to distinguish
> > whether a
> > read-only BG is relocating or not.
> > 
> 
> This seems racey to me.  We remove the last part of the block group,
> it ends up 
> on the unused_bgs_list, we process this list, see that removed isn't
> set and we 
> skip it, then later we set removed, but it's too late.  I think the
> right way is 
> to actually do a transaction, set ->removed, manually add it to the 
> unused_bgs_list if it's not already, then end the transaction.  This
> way we are 
> guaranteed to have the bg on the list when it is ready to be
> removed.  This is 
> my analysis after looking at it for 10 seconds after being awake for
> like 30 
> minutes so if I'm missing something let me know.  Thanks,

I don't think a race will happen. Since we are holding
delete_unused_bgs_mutex here, btrfs_delte_unused_bgs() checks ->removed
flag after we unlock the mutex i.e. we setup the flag properly. For a
case btrfs_delete_usused_bgs() checks the BG before we hold
delte_unused_bgs_mutex, then that BG is removed by it (if it's empty)
and btrfs_relocate_chunk() should never see it.

Regards,
Naohiro

[PATCH 1/2] f2fs: fix minor typo

[Chao Yu]

Correct typo from 'destory' to 'destroy'.

Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 93c5e26..ff4b723 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2678,7 +2678,7 @@ int __init create_segment_manager_caches(void)
bio_entry_slab = f2fs_kmem_cache_create("bio_entry",
sizeof(struct bio_entry));
if (!bio_entry_slab)
-   goto destory_discard_entry;
+   goto destroy_discard_entry;
 
sit_entry_set_slab = f2fs_kmem_cache_create("sit_entry_set",
sizeof(struct sit_entry_set));
@@ -2695,7 +2695,7 @@ destroy_sit_entry_set:
kmem_cache_destroy(sit_entry_set_slab);
 destroy_bio_entry:
kmem_cache_destroy(bio_entry_slab);
-destory_discard_entry:
+destroy_discard_entry:
kmem_cache_destroy(discard_entry_slab);
 fail:
return -ENOMEM;
-- 
2.8.2.311.gee88674

[PATCH 1/2] f2fs: fix minor typo

[Chao Yu]

Correct typo from 'destory' to 'destroy'.

Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 93c5e26..ff4b723 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2678,7 +2678,7 @@ int __init create_segment_manager_caches(void)
bio_entry_slab = f2fs_kmem_cache_create("bio_entry",
sizeof(struct bio_entry));
if (!bio_entry_slab)
-   goto destory_discard_entry;
+   goto destroy_discard_entry;
 
sit_entry_set_slab = f2fs_kmem_cache_create("sit_entry_set",
sizeof(struct sit_entry_set));
@@ -2695,7 +2695,7 @@ destroy_sit_entry_set:
kmem_cache_destroy(sit_entry_set_slab);
 destroy_bio_entry:
kmem_cache_destroy(bio_entry_slab);
-destory_discard_entry:
+destroy_discard_entry:
kmem_cache_destroy(discard_entry_slab);
 fail:
return -ENOMEM;
-- 
2.8.2.311.gee88674

[PATCH 2/2] f2fs: fix to detect temporary name of multimedia file

[Chao Yu]

Some applications may create multimeida file with temporary name like
'*.jpg.tmp' or '*.mp4.tmp', then rename to '*.jpg' or '*.mp4'.

Now, f2fs can only detect multimedia filename with specified format:
"filename + '.' + extension", so it will make f2fs missing to detect
multimedia file with special temporary name, result in failing to set
cold flag on file.

This patch enhances detection flow for enabling lookup extension in the
middle of temporary filename.

Reported-by: Xue Liu 
Signed-off-by: Chao Yu 
---
 fs/f2fs/namei.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 73fa356..bfcd9da 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -91,18 +91,23 @@ static int is_multimedia_file(const unsigned char *s, const 
char *sub)
 {
size_t slen = strlen(s);
size_t sublen = strlen(sub);
+   int i;
 
/*
 * filename format of multimedia file should be defined as:
-* "filename + '.' + extension".
+* "filename + '.' + extension + (optional: '.' + temp extension)".
 */
if (slen < sublen + 2)
return 0;
 
-   if (s[slen - sublen - 1] != '.')
-   return 0;
+   for (i = 1; i < slen - sublen; i++) {
+   if (s[i] != '.')
+   continue;
+   if (!strncasecmp(s + i + 1, sub, sublen))
+   return 1;
+   }
 
-   return !strncasecmp(s + slen - sublen, sub, sublen);
+   return 0;
 }
 
 /*
-- 
2.8.2.311.gee88674

[PATCH 2/2] f2fs: fix to detect temporary name of multimedia file

[Chao Yu]

Some applications may create multimeida file with temporary name like
'*.jpg.tmp' or '*.mp4.tmp', then rename to '*.jpg' or '*.mp4'.

Now, f2fs can only detect multimedia filename with specified format:
"filename + '.' + extension", so it will make f2fs missing to detect
multimedia file with special temporary name, result in failing to set
cold flag on file.

This patch enhances detection flow for enabling lookup extension in the
middle of temporary filename.

Reported-by: Xue Liu 
Signed-off-by: Chao Yu 
---
 fs/f2fs/namei.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 73fa356..bfcd9da 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -91,18 +91,23 @@ static int is_multimedia_file(const unsigned char *s, const 
char *sub)
 {
size_t slen = strlen(s);
size_t sublen = strlen(sub);
+   int i;
 
/*
 * filename format of multimedia file should be defined as:
-* "filename + '.' + extension".
+* "filename + '.' + extension + (optional: '.' + temp extension)".
 */
if (slen < sublen + 2)
return 0;
 
-   if (s[slen - sublen - 1] != '.')
-   return 0;
+   for (i = 1; i < slen - sublen; i++) {
+   if (s[i] != '.')
+   continue;
+   if (!strncasecmp(s + i + 1, sub, sublen))
+   return 1;
+   }
 
-   return !strncasecmp(s + slen - sublen, sub, sublen);
+   return 0;
 }
 
 /*
-- 
2.8.2.311.gee88674

Re: [PATCH v6 1/2] clk: uniphier: add core support code for UniPhier clock driver

[Masahiro Yamada]

Hi Stephen,


2016-08-30 3:22 GMT+09:00 Stephen Boyd :
> On 08/29, Masahiro Yamada wrote:
>> Hi Stephen,
>>
>>
>> 2016-08-20 4:16 GMT+09:00 Stephen Boyd :
>> >>
>> >> >> +
>> >> >> + parent = of_get_parent(dev->of_node); /* parent should be syscon 
>> >> >> node */
>> >> >> + regmap = syscon_node_to_regmap(parent);
>> >> >> + of_node_put(parent);
>> >> >
>> >> > devm_get_regmap(dev->parent) should work then? Why do we need to
>> >> > use OF APIs?
>> >>
>> >> "git grep devm_get_regmap" did not hit anything.
>> >>
>> >> Where is it defined?
>> >>
>> >
>> > Sorry I meant dev_get_regmap().
>> >
>>
>> I tried this, but it did not work.
>>
>> To make dev_get_regmap() work,
>> the parent device needs to call dev_regmap_init_mmio() beforehand.
>>
>>
>> Since commit bdb0066df96e74a4002125467ebe459feff1ebef
>> (mfd: syscon: Decouple syscon interface from platform devices),
>> syscon_probe() is not called for platform devices,
>> so that never happens.
>>
>
> Ok. Is the syscon also a simple-mfd?
>
> It sounds like there's a device for the parent, but we've failed
> to attach a regmap to it. Maybe the core DT code should assign
> the regmap to the parent device when it creates it so that child
> devices don't need to know this detail? It could look for
> simple-mfd devices with compatible = "syscon" and then create the
> regmap? Here's a totally untested patch for that.
>
> 8<
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 2f2225e845ef..5f7d3f015b82 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -136,6 +136,17 @@ struct regmap *syscon_node_to_regmap(struct device_node 
> *np)
>  }
>  EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
>
> +int device_attach_syscon(struct device *dev)
> +{
> +   struct regmap *regmap;
> +
> +   regmap = syscon_node_to_regmap(dev->of_node);
> +   if (IS_ERR(regmap))
> +   return PTR_ERR(regmap);
> +
> +   return regmap_attach_dev(dev, regmap, _regmap_config);
> +}
> +
>  struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
>  {
> struct device_node *syscon_np;
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 8aa197691074..58a018e15006 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  const struct of_device_id of_default_bus_match_table[] = {
> { .compatible = "simple-bus", },
> @@ -383,7 +384,12 @@ static int of_platform_bus_create(struct device_node 
> *bus,
> return 0;
> }
>
> +
> dev = of_platform_device_create_pdata(bus, bus_id, platform_data, 
> parent);
> +   if (of_device_is_compatible(bus, "simple-mfd") &&
> +   of_device_is_compatible(bus, "syscon"))
> +   device_attach_syscon(>dev);
> +
> if (!dev || !of_match_node(matches, bus))
> return 0;
>
> diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
> index 40a76b97b7ab..e19e5d15f4e6 100644
> --- a/include/linux/mfd/syscon.h
> +++ b/include/linux/mfd/syscon.h
> @@ -18,9 +18,11 @@
>  #include 
>  #include 
>
> +struct device;
>  struct device_node;
>
>  #ifdef CONFIG_MFD_SYSCON
> +extern int device_attach_syscon(struct device *dev);
>  extern struct regmap *syscon_node_to_regmap(struct device_node *np);
>  extern struct regmap *syscon_regmap_lookup_by_compatible(const char *s);
>  extern struct regmap *syscon_regmap_lookup_by_pdevname(const char *s);
> @@ -28,6 +30,11 @@ extern struct regmap *syscon_regmap_lookup_by_phandle(
> struct device_node *np,
> const char *property);
>  #else
> +static inline int device_attach_syscon(struct device *dev)
> +{
> +   return 0;
> +}
> +
>  static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
>  {
> return ERR_PTR(-ENOTSUPP);


I was not quire sure about this,
but maybe worth submitting to DT subsystem?

Anyway, I will go with syscon_node_to_regmap() for v7.
Of course, I am happy to replace it with dev_get_regmap()
when the issue is solved in the mainline.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v6 1/2] clk: uniphier: add core support code for UniPhier clock driver

[Masahiro Yamada]

Hi Stephen,


2016-08-30 3:22 GMT+09:00 Stephen Boyd :
> On 08/29, Masahiro Yamada wrote:
>> Hi Stephen,
>>
>>
>> 2016-08-20 4:16 GMT+09:00 Stephen Boyd :
>> >>
>> >> >> +
>> >> >> + parent = of_get_parent(dev->of_node); /* parent should be syscon 
>> >> >> node */
>> >> >> + regmap = syscon_node_to_regmap(parent);
>> >> >> + of_node_put(parent);
>> >> >
>> >> > devm_get_regmap(dev->parent) should work then? Why do we need to
>> >> > use OF APIs?
>> >>
>> >> "git grep devm_get_regmap" did not hit anything.
>> >>
>> >> Where is it defined?
>> >>
>> >
>> > Sorry I meant dev_get_regmap().
>> >
>>
>> I tried this, but it did not work.
>>
>> To make dev_get_regmap() work,
>> the parent device needs to call dev_regmap_init_mmio() beforehand.
>>
>>
>> Since commit bdb0066df96e74a4002125467ebe459feff1ebef
>> (mfd: syscon: Decouple syscon interface from platform devices),
>> syscon_probe() is not called for platform devices,
>> so that never happens.
>>
>
> Ok. Is the syscon also a simple-mfd?
>
> It sounds like there's a device for the parent, but we've failed
> to attach a regmap to it. Maybe the core DT code should assign
> the regmap to the parent device when it creates it so that child
> devices don't need to know this detail? It could look for
> simple-mfd devices with compatible = "syscon" and then create the
> regmap? Here's a totally untested patch for that.
>
> 8<
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 2f2225e845ef..5f7d3f015b82 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -136,6 +136,17 @@ struct regmap *syscon_node_to_regmap(struct device_node 
> *np)
>  }
>  EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
>
> +int device_attach_syscon(struct device *dev)
> +{
> +   struct regmap *regmap;
> +
> +   regmap = syscon_node_to_regmap(dev->of_node);
> +   if (IS_ERR(regmap))
> +   return PTR_ERR(regmap);
> +
> +   return regmap_attach_dev(dev, regmap, _regmap_config);
> +}
> +
>  struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
>  {
> struct device_node *syscon_np;
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 8aa197691074..58a018e15006 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  const struct of_device_id of_default_bus_match_table[] = {
> { .compatible = "simple-bus", },
> @@ -383,7 +384,12 @@ static int of_platform_bus_create(struct device_node 
> *bus,
> return 0;
> }
>
> +
> dev = of_platform_device_create_pdata(bus, bus_id, platform_data, 
> parent);
> +   if (of_device_is_compatible(bus, "simple-mfd") &&
> +   of_device_is_compatible(bus, "syscon"))
> +   device_attach_syscon(>dev);
> +
> if (!dev || !of_match_node(matches, bus))
> return 0;
>
> diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
> index 40a76b97b7ab..e19e5d15f4e6 100644
> --- a/include/linux/mfd/syscon.h
> +++ b/include/linux/mfd/syscon.h
> @@ -18,9 +18,11 @@
>  #include 
>  #include 
>
> +struct device;
>  struct device_node;
>
>  #ifdef CONFIG_MFD_SYSCON
> +extern int device_attach_syscon(struct device *dev);
>  extern struct regmap *syscon_node_to_regmap(struct device_node *np);
>  extern struct regmap *syscon_regmap_lookup_by_compatible(const char *s);
>  extern struct regmap *syscon_regmap_lookup_by_pdevname(const char *s);
> @@ -28,6 +30,11 @@ extern struct regmap *syscon_regmap_lookup_by_phandle(
> struct device_node *np,
> const char *property);
>  #else
> +static inline int device_attach_syscon(struct device *dev)
> +{
> +   return 0;
> +}
> +
>  static inline struct regmap *syscon_node_to_regmap(struct device_node *np)
>  {
> return ERR_PTR(-ENOTSUPP);


I was not quire sure about this,
but maybe worth submitting to DT subsystem?

Anyway, I will go with syscon_node_to_regmap() for v7.
Of course, I am happy to replace it with dev_get_regmap()
when the issue is solved in the mainline.



-- 
Best Regards
Masahiro Yamada

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Sergey Senozhatsky]

Hello,

On (09/05/16 11:18), Minchan Kim wrote:
[..]
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
> 
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?

you are right Minchan, that was exactly my point. every compressed page
that does not end up in huge_object zspage should result in some memory
saving (somewhere in the range from bytes to kilobytes).

> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.

a good theory.

in general, a selective compression of N first pages that fall under the
given compression limit is not the same as a selective compression of N
"best" compressible pages. so I'm a bit uncertain about the guarantees
that the patch can provide.

let's assume the following case.
- zram compression size limit set to 2400 bytes (only pages smaller than
  that will be stored in zsmalloc)
- first K pages to swapout have compression size of 2350 +/- 10%
- next L pages have compression size of 2500 +/- 10%
- last M pages are un-compressible - PAGE_SIZE.
- zram disksize can fit N pages
- N > K + L

so instead of compressing and swapping out K + L pages, you would compress
only K pages, leaving (L + M) * PAGE_SIZE untouched. thus I'd say that we
might have bigger chances of LMK/OOM/etc. in some cases.

-ss

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu.h

between commit:

  566153874951 ("drm/amdgpu: fix lru size grouping v2")

from Linus' tree and commit:

  c632d7994360 ("amdgpu: move ttm stuff to amdgpu_ttm.h")

from the drm tree.

I fixed it up (the code move was fixed up in another commit, so I just
removed the former change to this file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Sergey Senozhatsky]

Hello,

On (09/05/16 11:18), Minchan Kim wrote:
[..]
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
> 
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
> memory compared to old so why does your patch decrease the number of
> lowmemory killing?

you are right Minchan, that was exactly my point. every compressed page
that does not end up in huge_object zspage should result in some memory
saving (somewhere in the range from bytes to kilobytes).

> A thing I can imagine is without this feature, zram could be full of
> uncompressible pages so good-compressible page cannot be swapped out.

a good theory.

in general, a selective compression of N first pages that fall under the
given compression limit is not the same as a selective compression of N
"best" compressible pages. so I'm a bit uncertain about the guarantees
that the patch can provide.

let's assume the following case.
- zram compression size limit set to 2400 bytes (only pages smaller than
  that will be stored in zsmalloc)
- first K pages to swapout have compression size of 2350 +/- 10%
- next L pages have compression size of 2500 +/- 10%
- last M pages are un-compressible - PAGE_SIZE.
- zram disksize can fit N pages
- N > K + L

so instead of compressing and swapping out K + L pages, you would compress
only K pages, leaving (L + M) * PAGE_SIZE untouched. thus I'd say that we
might have bigger chances of LMK/OOM/etc. in some cases.

-ss

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu.h

between commit:

  566153874951 ("drm/amdgpu: fix lru size grouping v2")

from Linus' tree and commit:

  c632d7994360 ("amdgpu: move ttm stuff to amdgpu_ttm.h")

from the drm tree.

I fixed it up (the code move was fixed up in another commit, so I just
removed the former change to this file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

[Chen Yu]

On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner wrote:
> > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > > People reported that they can not do a poweroff nor a
> > > suspend to ram on their Mac Pro 11. After some investigations
> > > it was found that, once the PCI bridge :00:1c.0 reassigns its
> > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > [mem 0x7fc0-0x7fdf 64bit pref]), the region of ACPI
> > > io resource 0x1804 becomes unaccessible immediately, where the
> > > ACPI Sleep register is located, as a result neither poweroff(S5)
> > > nor suspend to ram(S3) works.
> > 
> > To provide a bit more context:
> > 
> > The root port in question (:00:1c.0) is not listed in the DSDT.
> > On macOS, only devices present in the ACPI namespace are incorporated
> > into the I/O Kit registry. Consequently macOS pretends that this root
> > port doesn't exist. It's not listed in the "ioreg -l" output and thus
> > no driver is attached to this device.
> > 
> > So what we're dealing with is sloppiness on the part of Apple:
> > Some engineer probably forgot to disable this unused root port
> > and they didn't notice it during testing because their OS ignores
> > such devices.
> > 
> > We could in principle achieve the same behaviour by adding a PCI
> > device only if it has an ACPI companion, perhaps quirk this only
> > to Macs. I'm not sure if that's the right thing to do though.
> > What if they hide devices from macOS but we want to access them
> > on Linux?
> > 
> > What's really odd is that changing *memory* windows affects
> > accessibility of *I/O ports*.
> > 
> > One theory would be that I/O ports are somehow mapped into memory.
> > The GPIO pins of Intel chipsets are usually accessible through
> > I/O ports, but I've recently looked at the DSDT of the newest
> > MacBook9,1 (2016) and it looks like they're now accessed through
> > SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> > about these intricacies of their chipsets.
> 
> Hey, look, Chen Yu works at Intel :)
>
Ah yes, please give me some time and I'll try to search for related info
and give feeback later.
> This apparent connection between memory windows and I/O port
> accessibility is indeed very concerning.
> 
> I know there are PCI host bridges with windows that translate CPU
> memory accesses into PCI I/O port accesses.  If this is one of them,
> and it has such a window enabled at the address we happened to choose
> for the mem window, that would be a problem.
> 
> I assume this would be documented somewhere in the chipset datasheet.
> 
> > If I/O ports are indeed mapped into memory, we need to find a way
> > to identify and reserve that region. So while this patch seems
> > like a workable and sufficiently small fix, it might mask a larger
> > underlying issue. It's certainly a problem though that these
> > machines currently cannot power off or suspend.
> > 
> > FWIW, we have a somewhat similar issue with the Apple gmux
> > (a microcontroller built into dual GPU MacBook Pros). That chip
> > is attached to the LPC bus and accessed through I/O ports.
> > It turns out that once VGA IO is locked to the discrete GPU
> > using vgaarb, gmux' I/O ports suddenly become inaccessible.
> > Apparently its I/O ports are routed to the secondary PCI bus
> > to which the discrete GPU is connected, and no longer to the
> > root bus on which the LPC bridge resides. However gmux' I/O ports
> > are in the 0x700-0x7ff range, whereas the VGA registers are in
> > the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> > of Intel chipsets with regards to I/O accessibility.
> > 

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

[Chen Yu]

On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner wrote:
> > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > > People reported that they can not do a poweroff nor a
> > > suspend to ram on their Mac Pro 11. After some investigations
> > > it was found that, once the PCI bridge :00:1c.0 reassigns its
> > > mm windows to ([mem 0x7fa0-0x7fbf] and
> > > [mem 0x7fc0-0x7fdf 64bit pref]), the region of ACPI
> > > io resource 0x1804 becomes unaccessible immediately, where the
> > > ACPI Sleep register is located, as a result neither poweroff(S5)
> > > nor suspend to ram(S3) works.
> > 
> > To provide a bit more context:
> > 
> > The root port in question (:00:1c.0) is not listed in the DSDT.
> > On macOS, only devices present in the ACPI namespace are incorporated
> > into the I/O Kit registry. Consequently macOS pretends that this root
> > port doesn't exist. It's not listed in the "ioreg -l" output and thus
> > no driver is attached to this device.
> > 
> > So what we're dealing with is sloppiness on the part of Apple:
> > Some engineer probably forgot to disable this unused root port
> > and they didn't notice it during testing because their OS ignores
> > such devices.
> > 
> > We could in principle achieve the same behaviour by adding a PCI
> > device only if it has an ACPI companion, perhaps quirk this only
> > to Macs. I'm not sure if that's the right thing to do though.
> > What if they hide devices from macOS but we want to access them
> > on Linux?
> > 
> > What's really odd is that changing *memory* windows affects
> > accessibility of *I/O ports*.
> > 
> > One theory would be that I/O ports are somehow mapped into memory.
> > The GPIO pins of Intel chipsets are usually accessible through
> > I/O ports, but I've recently looked at the DSDT of the newest
> > MacBook9,1 (2016) and it looks like they're now accessed through
> > SystemMemory instead of SystemIO. Perhaps someone at Intel knows
> > about these intricacies of their chipsets.
> 
> Hey, look, Chen Yu works at Intel :)
>
Ah yes, please give me some time and I'll try to search for related info
and give feeback later.
> This apparent connection between memory windows and I/O port
> accessibility is indeed very concerning.
> 
> I know there are PCI host bridges with windows that translate CPU
> memory accesses into PCI I/O port accesses.  If this is one of them,
> and it has such a window enabled at the address we happened to choose
> for the mem window, that would be a problem.
> 
> I assume this would be documented somewhere in the chipset datasheet.
> 
> > If I/O ports are indeed mapped into memory, we need to find a way
> > to identify and reserve that region. So while this patch seems
> > like a workable and sufficiently small fix, it might mask a larger
> > underlying issue. It's certainly a problem though that these
> > machines currently cannot power off or suspend.
> > 
> > FWIW, we have a somewhat similar issue with the Apple gmux
> > (a microcontroller built into dual GPU MacBook Pros). That chip
> > is attached to the LPC bus and accessed through I/O ports.
> > It turns out that once VGA IO is locked to the discrete GPU
> > using vgaarb, gmux' I/O ports suddenly become inaccessible.
> > Apparently its I/O ports are routed to the secondary PCI bus
> > to which the discrete GPU is connected, and no longer to the
> > root bus on which the LPC bridge resides. However gmux' I/O ports
> > are in the 0x700-0x7ff range, whereas the VGA registers are in
> > the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
> > of Intel chipsets with regards to I/O accessibility.
> > 

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/drm_crtc.c

between commit:

  6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET")

from Linus' tree and commit:

  f837297ad824 ("drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/drm_crtc.c
index ddebe54cd5ca,a33dab27bb0d..
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@@ -5402,13 -1915,19 +1915,22 @@@ int drm_mode_page_flip_ioctl(struct drm
struct drm_crtc *crtc;
struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
+   u32 target_vblank = page_flip->sequence;
int ret = -EINVAL;
  
 +  if (!drm_core_check_feature(dev, DRIVER_MODESET))
 +  return -EINVAL;
 +
-   if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
-   page_flip->reserved != 0)
+   if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS)
+   return -EINVAL;
+ 
+   if (page_flip->sequence != 0 && !(page_flip->flags & 
DRM_MODE_PAGE_FLIP_TARGET))
+   return -EINVAL;
+ 
+   /* Only one of the DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags
+* can be specified
+*/
+   if ((page_flip->flags & DRM_MODE_PAGE_FLIP_TARGET) == 
DRM_MODE_PAGE_FLIP_TARGET)
return -EINVAL;
  
if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) && 
!dev->mode_config.async_page_flip)

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/drm_crtc.c

between commit:

  6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET")

from Linus' tree and commit:

  f837297ad824 ("drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/drm_crtc.c
index ddebe54cd5ca,a33dab27bb0d..
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@@ -5402,13 -1915,19 +1915,22 @@@ int drm_mode_page_flip_ioctl(struct drm
struct drm_crtc *crtc;
struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
+   u32 target_vblank = page_flip->sequence;
int ret = -EINVAL;
  
 +  if (!drm_core_check_feature(dev, DRIVER_MODESET))
 +  return -EINVAL;
 +
-   if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
-   page_flip->reserved != 0)
+   if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS)
+   return -EINVAL;
+ 
+   if (page_flip->sequence != 0 && !(page_flip->flags & 
DRM_MODE_PAGE_FLIP_TARGET))
+   return -EINVAL;
+ 
+   /* Only one of the DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags
+* can be specified
+*/
+   if ((page_flip->flags & DRM_MODE_PAGE_FLIP_TARGET) == 
DRM_MODE_PAGE_FLIP_TARGET)
return -EINVAL;
  
if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) && 
!dev->mode_config.async_page_flip)

Re: [PATCH 3/6] clk: sunxi-ng: Add N-class clocks support

[Chen-Yu Tsai]

On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard
 wrote:
> Add support for the class with a single factor, N, being a multiplier.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 3/6] clk: sunxi-ng: Add N-class clocks support

[Chen-Yu Tsai]

On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard
 wrote:
> Add support for the class with a single factor, N, being a multiplier.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

[RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

[Balbir Singh]

The origin of the issue I've seen is related to
a missing memory barrier between check for task->state and
the check for task->on_rq.

The task being woken up is already awake from a schedule()
and is doing the following

do {
schedule()
set_current_state(TASK_(UN)INTERRUPTIBLE);
} while (!cond);

The waker, actually gets stuck doing the following in
try_to_wake_up

while (p->on_cpu)
cpu_relax();

Analysis

The instance I've seen involves the following race

CPU1CPU2

while () {
  if (cond)
break;
  do {
schedule();
set_current_state(TASK_UN..)
  } while (!cond);
wakeup_routine()
  spin_lock_irqsave(wait_lock)
  raw_spin_lock_irqsave(wait_lock)wake_up_process()
} try_to_wake_up()
set_current_state(TASK_RUNNING);  ..
list_del();

CPU2 wakes up CPU1, but before it can get the wait_lock and set
current state to TASK_RUNNING the following occurs

CPU3
wakeup_routine()
raw_spin_lock_irqsave(wait_lock)
if (!list_empty)
  wake_up_process()
  try_to_wake_up()
  raw_spin_lock_irqsave(p->pi_lock)
  ..
  if (p->on_rq && ttwu_wakeup())
  ..
  while (p->on_cpu)
cpu_relax()
  ..

CPU3 tries to wake up the task on CPU1 again since it finds
it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
after CPU2, CPU3 got it.

CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
the task is spinning on the wait_lock. Interestingly since p->on_rq
is checked under pi_lock, I've noticed that try_to_wake_up() finds
p->on_rq to be 0. This was the most confusing bit of the analysis,
but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
check is not reliable without this fix IMHO. The race is visible
(based on the analysis) only when ttwu_queue() does a remote wakeup
via ttwu_queue_remote. In which case the p->on_rq change is not
done uder the pi_lock.

The result is that after a while the entire system locks up on
the raw_spin_irqlock_save(wait_lock) and the holder spins infintely

Reproduction of the issue

The issue can be reproduced after a long run on my system with 80
threads and having to tweak available memory to very low and running
memory stress-ng mmapfork test. It usually takes a long time to
reproduce. I am trying to work on a test case that can reproduce
the issue faster, but thats work in progress. I am still testing the
changes on my still in a loop and the tests seem OK thus far.

Big thanks to Benjamin and Nick for helping debug this as well.
Ben helped catch the missing barrier, Nick caught every missing
bit in my theory

Cc: Peter Zijlstra 
Cc: Nicholas Piggin 
Cc: Benjamin Herrenschmidt 

Signed-off-by: Balbir Singh 
---
 kernel/sched/core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2a906f2..582c684 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2016,6 +2016,17 @@ try_to_wake_up(struct task_struct *p, unsigned int 
state, int wake_flags)
success = 1; /* we're going to change ->state */
cpu = task_cpu(p);
 
+   /*
+* Ensure we see on_rq and p_state consistently
+*
+* For example in __rwsem_down_write_failed(), we have
+*[S] ->on_rq = 1   [L] ->state
+*MB RMB
+*[S] ->state = TASK_UNINTERRUPTIBLE[L] ->on_rq
+* In the absence of the RMB p->on_rq can be observed to be 0
+* and we end up spinning indefinitely in while (p->on_cpu)
+*/
+   smp_rmb();
if (p->on_rq && ttwu_remote(p, wake_flags))
goto stat;
 
-- 
2.5.5

[RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

[Balbir Singh]

The origin of the issue I've seen is related to
a missing memory barrier between check for task->state and
the check for task->on_rq.

The task being woken up is already awake from a schedule()
and is doing the following

do {
schedule()
set_current_state(TASK_(UN)INTERRUPTIBLE);
} while (!cond);

The waker, actually gets stuck doing the following in
try_to_wake_up

while (p->on_cpu)
cpu_relax();

Analysis

The instance I've seen involves the following race

CPU1CPU2

while () {
  if (cond)
break;
  do {
schedule();
set_current_state(TASK_UN..)
  } while (!cond);
wakeup_routine()
  spin_lock_irqsave(wait_lock)
  raw_spin_lock_irqsave(wait_lock)wake_up_process()
} try_to_wake_up()
set_current_state(TASK_RUNNING);  ..
list_del();

CPU2 wakes up CPU1, but before it can get the wait_lock and set
current state to TASK_RUNNING the following occurs

CPU3
wakeup_routine()
raw_spin_lock_irqsave(wait_lock)
if (!list_empty)
  wake_up_process()
  try_to_wake_up()
  raw_spin_lock_irqsave(p->pi_lock)
  ..
  if (p->on_rq && ttwu_wakeup())
  ..
  while (p->on_cpu)
cpu_relax()
  ..

CPU3 tries to wake up the task on CPU1 again since it finds
it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
after CPU2, CPU3 got it.

CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
the task is spinning on the wait_lock. Interestingly since p->on_rq
is checked under pi_lock, I've noticed that try_to_wake_up() finds
p->on_rq to be 0. This was the most confusing bit of the analysis,
but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
check is not reliable without this fix IMHO. The race is visible
(based on the analysis) only when ttwu_queue() does a remote wakeup
via ttwu_queue_remote. In which case the p->on_rq change is not
done uder the pi_lock.

The result is that after a while the entire system locks up on
the raw_spin_irqlock_save(wait_lock) and the holder spins infintely

Reproduction of the issue

The issue can be reproduced after a long run on my system with 80
threads and having to tweak available memory to very low and running
memory stress-ng mmapfork test. It usually takes a long time to
reproduce. I am trying to work on a test case that can reproduce
the issue faster, but thats work in progress. I am still testing the
changes on my still in a loop and the tests seem OK thus far.

Big thanks to Benjamin and Nick for helping debug this as well.
Ben helped catch the missing barrier, Nick caught every missing
bit in my theory

Cc: Peter Zijlstra 
Cc: Nicholas Piggin 
Cc: Benjamin Herrenschmidt 

Signed-off-by: Balbir Singh 
---
 kernel/sched/core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2a906f2..582c684 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2016,6 +2016,17 @@ try_to_wake_up(struct task_struct *p, unsigned int 
state, int wake_flags)
success = 1; /* we're going to change ->state */
cpu = task_cpu(p);
 
+   /*
+* Ensure we see on_rq and p_state consistently
+*
+* For example in __rwsem_down_write_failed(), we have
+*[S] ->on_rq = 1   [L] ->state
+*MB RMB
+*[S] ->state = TASK_UNINTERRUPTIBLE[L] ->on_rq
+* In the absence of the RMB p->on_rq can be observed to be 0
+* and we end up spinning indefinitely in while (p->on_cpu)
+*/
+   smp_rmb();
if (p->on_rq && ttwu_remote(p, wake_flags))
goto stat;
 
-- 
2.5.5

Re: chipidea: udc: kernel panic in isr_setup_status_phase

[Peter Chen]

On Fri, Sep 02, 2016 at 06:42:43PM +0200, Clemens Gruber wrote:
> On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> > Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> > as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> > the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> > cause the unstable for USB PHY. If possible, you can connect MAIN 5V
> > (if it exists) directly to USB_H1_VBUS to see if this problem is fixed.
> 
> Yes, USB_H1_VBUS is supplied from internal 5V and it is accurate (+/-
> 0.03V). The USB_H_EN signal enables USB_H1_VBUS through a MIC2026-1.
> 
> The USB_OTG_VBUS signal from the picture with 4.69V came from the host
> PC and is not under our control.
> 
> I read in the ReferenceManual that the USBPHY defaults to USB_H1_VBUS if
> both USB_OTG_VBUS and USB_H1_VBUS are available.
> If we imagine the following situation: USB OTG cable is plugged-in, the
> board is powered on, USB_OTG_VBUS is supplied externally and USBPHY uses
> it because USB_H1_EN is not high yet and did not enable USB_H1_VBUS.
> If the USBPHY started out being supplied by USB_OTG_VBUS and later on,
> USB_H1_VBUS comes up, will the USBPHY switch to USB_H1_VBUS immediately
> or stay at being supplied by USB_OTG_VBUS as long as that is available?

The USB LDO will use the higher voltage as input.

> 
> > Great. Can you see the sudden lower for vbus again? If it still exists, it 
> > may
> > be GND issue.
> 
> Yes it is still visible. Does not seem to be a problem though.
> 
> > Avoid NULL pointer deference is necessary. Patch is welcome :)
> 
> Yes, but should we also stop the gadget driver and print an error
> message? Or just return from the isr and neither report nor stop?
> 

How about below, it will set halt for device, and host will get stall
from the device.

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 0f692fc..3c46ccb 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -946,6 +946,11 @@ static int isr_setup_status_phase(struct ci_hdrc *ci)
int retval;
struct ci_hw_ep *hwep;
 
+   if (!ci->status) {
+   WARN_ON(1);
+   return -EPIPE;
+   }
+
hwep = (ci->ep0_dir == TX) ? ci->ep0out : ci->ep0in;
ci->status->context = ci;
ci->status->complete = isr_setup_status_complete;

-- 

Best Regards,
Peter Chen

Re: chipidea: udc: kernel panic in isr_setup_status_phase

[Peter Chen]

On Fri, Sep 02, 2016 at 06:42:43PM +0200, Clemens Gruber wrote:
> On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> > Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> > as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> > the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> > cause the unstable for USB PHY. If possible, you can connect MAIN 5V
> > (if it exists) directly to USB_H1_VBUS to see if this problem is fixed.
> 
> Yes, USB_H1_VBUS is supplied from internal 5V and it is accurate (+/-
> 0.03V). The USB_H_EN signal enables USB_H1_VBUS through a MIC2026-1.
> 
> The USB_OTG_VBUS signal from the picture with 4.69V came from the host
> PC and is not under our control.
> 
> I read in the ReferenceManual that the USBPHY defaults to USB_H1_VBUS if
> both USB_OTG_VBUS and USB_H1_VBUS are available.
> If we imagine the following situation: USB OTG cable is plugged-in, the
> board is powered on, USB_OTG_VBUS is supplied externally and USBPHY uses
> it because USB_H1_EN is not high yet and did not enable USB_H1_VBUS.
> If the USBPHY started out being supplied by USB_OTG_VBUS and later on,
> USB_H1_VBUS comes up, will the USBPHY switch to USB_H1_VBUS immediately
> or stay at being supplied by USB_OTG_VBUS as long as that is available?

The USB LDO will use the higher voltage as input.

> 
> > Great. Can you see the sudden lower for vbus again? If it still exists, it 
> > may
> > be GND issue.
> 
> Yes it is still visible. Does not seem to be a problem though.
> 
> > Avoid NULL pointer deference is necessary. Patch is welcome :)
> 
> Yes, but should we also stop the gadget driver and print an error
> message? Or just return from the isr and neither report nor stop?
> 

How about below, it will set halt for device, and host will get stall
from the device.

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 0f692fc..3c46ccb 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -946,6 +946,11 @@ static int isr_setup_status_phase(struct ci_hdrc *ci)
int retval;
struct ci_hw_ep *hwep;
 
+   if (!ci->status) {
+   WARN_ON(1);
+   return -EPIPE;
+   }
+
hwep = (ci->ep0_dir == TX) ? ci->ep0out : ci->ep0in;
ci->status->context = ci;
ci->status->complete = isr_setup_status_complete;

-- 

Best Regards,
Peter Chen

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/mediatek/mtk_eth_soc.c

between commits:

  d3bd1ce4db8e ("net: ethernet: mediatek: remove redundant free_irq for 
devm_request_irq allocated irq")
  7c6b0d76fa02 ("net: ethernet: mediatek: fix logic unbalance between probe and 
remove")

from the net tree and commits:

  45d339309f49 ("net: mediatek: remove unnecessary platform_set_drvdata()")
  bacfd110e059 ("net: ethernet: mediatek: modify to use the PDMA instead of the 
QDMA for Ethernet RX")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mediatek/mtk_eth_soc.c
index d9199151a83e,2dadfa961898..
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@@ -334,9 -338,12 +334,10 @@@ static void mtk_mdio_cleanup(struct mtk
return;
  
mdiobus_unregister(eth->mii_bus);
 -  of_node_put(eth->mii_bus->dev.of_node);
 -  mdiobus_free(eth->mii_bus);
  }
  
- static inline void mtk_irq_disable(struct mtk_eth *eth, u32 mask)
+ static inline void mtk_irq_disable(struct mtk_eth *eth,
+  unsigned reg, u32 mask)
  {
unsigned long flags;
u32 val;
@@@ -1501,7 -1513,11 +1508,8 @@@ static void mtk_uninit(struct net_devic
struct mtk_eth *eth = mac->hw;
  
phy_disconnect(mac->phy_dev);
-   mtk_irq_disable(eth, ~0);
 -  mtk_mdio_cleanup(eth);
+   mtk_irq_disable(eth, MTK_QDMA_INT_MASK, ~0);
+   mtk_irq_disable(eth, MTK_PDMA_INT_MASK, ~0);
 -  free_irq(eth->irq[1], dev);
 -  free_irq(eth->irq[2], dev);
  }
  
  static int mtk_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@@ -1913,8 -1920,6 +1921,7 @@@ static int mtk_remove(struct platform_d
netif_napi_del(>tx_napi);
netif_napi_del(>rx_napi);
mtk_cleanup(eth);
 +  mtk_mdio_cleanup(eth);
-   platform_set_drvdata(pdev, NULL);
  
return 0;
  }

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/mediatek/mtk_eth_soc.c

between commits:

  d3bd1ce4db8e ("net: ethernet: mediatek: remove redundant free_irq for 
devm_request_irq allocated irq")
  7c6b0d76fa02 ("net: ethernet: mediatek: fix logic unbalance between probe and 
remove")

from the net tree and commits:

  45d339309f49 ("net: mediatek: remove unnecessary platform_set_drvdata()")
  bacfd110e059 ("net: ethernet: mediatek: modify to use the PDMA instead of the 
QDMA for Ethernet RX")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mediatek/mtk_eth_soc.c
index d9199151a83e,2dadfa961898..
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@@ -334,9 -338,12 +334,10 @@@ static void mtk_mdio_cleanup(struct mtk
return;
  
mdiobus_unregister(eth->mii_bus);
 -  of_node_put(eth->mii_bus->dev.of_node);
 -  mdiobus_free(eth->mii_bus);
  }
  
- static inline void mtk_irq_disable(struct mtk_eth *eth, u32 mask)
+ static inline void mtk_irq_disable(struct mtk_eth *eth,
+  unsigned reg, u32 mask)
  {
unsigned long flags;
u32 val;
@@@ -1501,7 -1513,11 +1508,8 @@@ static void mtk_uninit(struct net_devic
struct mtk_eth *eth = mac->hw;
  
phy_disconnect(mac->phy_dev);
-   mtk_irq_disable(eth, ~0);
 -  mtk_mdio_cleanup(eth);
+   mtk_irq_disable(eth, MTK_QDMA_INT_MASK, ~0);
+   mtk_irq_disable(eth, MTK_PDMA_INT_MASK, ~0);
 -  free_irq(eth->irq[1], dev);
 -  free_irq(eth->irq[2], dev);
  }
  
  static int mtk_do_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@@ -1913,8 -1920,6 +1921,7 @@@ static int mtk_remove(struct platform_d
netif_napi_del(>tx_napi);
netif_napi_del(>rx_napi);
mtk_cleanup(eth);
 +  mtk_mdio_cleanup(eth);
-   platform_set_drvdata(pdev, NULL);
  
return 0;
  }

Re: [RFC PATCH V5 3/5] PCI: Check platform specific ECAM quirks

[Bjorn Helgaas]

On Mon, Aug 08, 2016 at 03:05:39PM +0200, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list (static array),
> matches against  and
> returns pci_config_window structure with fancy PCI config ops.
> oem_id, oem_table_id and rev come from MCFG table standard header.
> 
> It is possible to define custom init call which is responsible for
> setting up PCI configuration access accordingly to quirk requirements.
> If custom init call is not defined, use standard 
> pci_acpi_setup_ecam_mapping().
> 
> pci_generic_ecam_ops will be used for platforms free from quirks.
> 
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Dongdong Liu 
> Signed-off-by: Christopher Covington 
> ---
>  drivers/pci/host/Makefile  |  1 +
>  drivers/pci/host/mcfg-quirks.c | 86 
> ++
>  drivers/pci/host/mcfg-quirks.h | 20 ++
>  include/linux/pci-acpi.h   |  2 +
>  4 files changed, 109 insertions(+)
>  create mode 100644 drivers/pci/host/mcfg-quirks.c
>  create mode 100644 drivers/pci/host/mcfg-quirks.h
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 8843410..500cf78 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
>  obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
>  obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
>  obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> +obj-$(CONFIG_ACPI_MCFG) += mcfg-quirks.o
> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
> new file mode 100644
> index 000..aa9907b
> --- /dev/null
> +++ b/drivers/pci/host/mcfg-quirks.c
> @@ -0,0 +1,86 @@
> +/*
> + * Copyright (C) 2016 Semihalf
> + *   Author: Tomasz Nowicki 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation (the "GPL").
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License version 2 (GPLv2) for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * version 2 (GPLv2) along with this source code.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mcfg-quirks.h"
> +
> +struct pci_cfg_fixup {
> + char oem_id[ACPI_OEM_ID_SIZE + 1];
> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> + u32 oem_revision;
> + struct resource domain_range;
> + struct resource bus_range;
> + struct pci_ops *ops;
> + struct pci_config_window *(*init)(struct acpi_pci_root *root,
> +   struct pci_ops *ops);
> +};
> +
> +#define MCFG_DOM_RANGE(start, end)   DEFINE_RES_NAMED((start),   \
> + ((end) - (start) + 1), NULL, 0)
> +#define MCFG_DOM_ANY MCFG_DOM_RANGE(0x0, 0x)
> +#define MCFG_BUS_RANGE(start, end)   DEFINE_RES_NAMED((start),   \
> + ((end) - (start) + 1),  \
> + NULL, IORESOURCE_BUS)
> +#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
> +
> +static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
> +/*   { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
> +};
> +
> +static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
> +  struct acpi_table_header *mcfg_header)
> +{
> + return (!memcmp(f->oem_id, mcfg_header->oem_id, ACPI_OEM_ID_SIZE) &&
> + !memcmp(f->oem_table_id, mcfg_header->oem_table_id,
> + ACPI_OEM_TABLE_ID_SIZE) &&
> + f->oem_revision == mcfg_header->oem_revision);
> +}
> +
> +struct pci_config_window *pci_mcfg_match_quirks(struct acpi_pci_root *root)
> +{
> + struct resource dom_res = MCFG_DOM_RANGE(root->segment, root->segment);
> + struct resource *bus_res = >secondary;
> + struct pci_cfg_fixup *f = mcfg_quirks;
> + struct acpi_table_header *mcfg_header;
> + acpi_status status;
> + int i;
> +
> + status = acpi_get_table(ACPI_SIG_MCFG, 0, _header);
> + if (ACPI_FAILURE(status))
> + return NULL;

I remember working out why pci_mcfg_parse() has to cache the data from
MCFG, but I don't remember the actual reason...  a comment there would
have been helpful.  Anyway, now I wonder why it's OK to call
acpi_get_table(ACPI_SIG_MCFG) again here.  I 

Re: [RFC PATCH V5 3/5] PCI: Check platform specific ECAM quirks

[Bjorn Helgaas]

On Mon, Aug 08, 2016 at 03:05:39PM +0200, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list (static array),
> matches against  and
> returns pci_config_window structure with fancy PCI config ops.
> oem_id, oem_table_id and rev come from MCFG table standard header.
> 
> It is possible to define custom init call which is responsible for
> setting up PCI configuration access accordingly to quirk requirements.
> If custom init call is not defined, use standard 
> pci_acpi_setup_ecam_mapping().
> 
> pci_generic_ecam_ops will be used for platforms free from quirks.
> 
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Dongdong Liu 
> Signed-off-by: Christopher Covington 
> ---
>  drivers/pci/host/Makefile  |  1 +
>  drivers/pci/host/mcfg-quirks.c | 86 
> ++
>  drivers/pci/host/mcfg-quirks.h | 20 ++
>  include/linux/pci-acpi.h   |  2 +
>  4 files changed, 109 insertions(+)
>  create mode 100644 drivers/pci/host/mcfg-quirks.c
>  create mode 100644 drivers/pci/host/mcfg-quirks.h
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 8843410..500cf78 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
>  obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
>  obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
>  obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> +obj-$(CONFIG_ACPI_MCFG) += mcfg-quirks.o
> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
> new file mode 100644
> index 000..aa9907b
> --- /dev/null
> +++ b/drivers/pci/host/mcfg-quirks.c
> @@ -0,0 +1,86 @@
> +/*
> + * Copyright (C) 2016 Semihalf
> + *   Author: Tomasz Nowicki 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation (the "GPL").
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License version 2 (GPLv2) for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * version 2 (GPLv2) along with this source code.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mcfg-quirks.h"
> +
> +struct pci_cfg_fixup {
> + char oem_id[ACPI_OEM_ID_SIZE + 1];
> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> + u32 oem_revision;
> + struct resource domain_range;
> + struct resource bus_range;
> + struct pci_ops *ops;
> + struct pci_config_window *(*init)(struct acpi_pci_root *root,
> +   struct pci_ops *ops);
> +};
> +
> +#define MCFG_DOM_RANGE(start, end)   DEFINE_RES_NAMED((start),   \
> + ((end) - (start) + 1), NULL, 0)
> +#define MCFG_DOM_ANY MCFG_DOM_RANGE(0x0, 0x)
> +#define MCFG_BUS_RANGE(start, end)   DEFINE_RES_NAMED((start),   \
> + ((end) - (start) + 1),  \
> + NULL, IORESOURCE_BUS)
> +#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
> +
> +static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
> +/*   { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
> +};
> +
> +static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
> +  struct acpi_table_header *mcfg_header)
> +{
> + return (!memcmp(f->oem_id, mcfg_header->oem_id, ACPI_OEM_ID_SIZE) &&
> + !memcmp(f->oem_table_id, mcfg_header->oem_table_id,
> + ACPI_OEM_TABLE_ID_SIZE) &&
> + f->oem_revision == mcfg_header->oem_revision);
> +}
> +
> +struct pci_config_window *pci_mcfg_match_quirks(struct acpi_pci_root *root)
> +{
> + struct resource dom_res = MCFG_DOM_RANGE(root->segment, root->segment);
> + struct resource *bus_res = >secondary;
> + struct pci_cfg_fixup *f = mcfg_quirks;
> + struct acpi_table_header *mcfg_header;
> + acpi_status status;
> + int i;
> +
> + status = acpi_get_table(ACPI_SIG_MCFG, 0, _header);
> + if (ACPI_FAILURE(status))
> + return NULL;

I remember working out why pci_mcfg_parse() has to cache the data from
MCFG, but I don't remember the actual reason...  a comment there would
have been helpful.  Anyway, now I wonder why it's OK to call
acpi_get_table(ACPI_SIG_MCFG) again here.  I guess I'd be inclined to
just cache the OEM info along with the rest of the data so you don't
have to get the table again here.

> + 

Re: [PATCH v3 10/22] usb: chipidea: Consolidate extcon notifiers

[Peter Chen]

On Fri, Sep 02, 2016 at 06:03:06PM -0700, Stephen Boyd wrote:
> On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen  wrote:
> > On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
> >>
> >>
> >>   if (cable->state)
> >> - val |= OTGSC_ID;
> >> + val &= ~OTGSC_ID; /* A device */
> >>   else
> >> - val &= ~OTGSC_ID;
> >> + val |= OTGSC_ID; /* B device */

One more comment, would you change the comment to "host" and "device"?
Unless we are supporting OTG-compliance device, otherwise, we should
not mention "A" or "B" for USB device.

Peter
> >>
> >>   if (cable->enabled)
> >>   val |= OTGSC_IDIE;
> >
> > /**
> >  * struct ci_hdrc_cable - structure for external connector cable state 
> > tracking
> >  * @state: current state of the line
> >
> > You may change the name of variable "state" to "connected", per I
> > understand, it has changed to the meaning of connected status for your 
> > patch.
> >
> 
> Ok sure.

-- 

Best Regards,
Peter Chen

Re: [PATCH v3 10/22] usb: chipidea: Consolidate extcon notifiers

[Peter Chen]

On Fri, Sep 02, 2016 at 06:03:06PM -0700, Stephen Boyd wrote:
> On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen  wrote:
> > On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
> >>
> >>
> >>   if (cable->state)
> >> - val |= OTGSC_ID;
> >> + val &= ~OTGSC_ID; /* A device */
> >>   else
> >> - val &= ~OTGSC_ID;
> >> + val |= OTGSC_ID; /* B device */

One more comment, would you change the comment to "host" and "device"?
Unless we are supporting OTG-compliance device, otherwise, we should
not mention "A" or "B" for USB device.

Peter
> >>
> >>   if (cable->enabled)
> >>   val |= OTGSC_IDIE;
> >
> > /**
> >  * struct ci_hdrc_cable - structure for external connector cable state 
> > tracking
> >  * @state: current state of the line
> >
> > You may change the name of variable "state" to "connected", per I
> > understand, it has changed to the meaning of connected status for your 
> > patch.
> >
> 
> Ok sure.

-- 

Best Regards,
Peter Chen

Re: [PATCH] ARM: imx: (trivial) fix typo and grammar

[Shawn Guo]

On Fri, Sep 02, 2016 at 10:34:40AM +0200, Martin Kaiser wrote:
> Signed-off-by: Martin Kaiser 

Applied, thanks.

> ---
>  arch/arm/mach-imx/hardware.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/hardware.h b/arch/arm/mach-imx/hardware.h
> index a42a6df..90e10cb 100644
> --- a/arch/arm/mach-imx/hardware.h
> +++ b/arch/arm/mach-imx/hardware.h
> @@ -120,7 +120,7 @@
>   .type = _type,  \
>  }
>  
> -/* There's a off-by-one betweem the gpio bank number and the gpiochip */
> +/* There's an off-by-one between the gpio bank number and the gpiochip */
>  /* range e.g. GPIO_1_5 is gpio 5 under linux */
>  #define IMX_GPIO_NR(bank, nr)(((bank) - 1) * 32 + (nr))
>  
> -- 
> 1.7.10.4
> 

Re: [PATCH] ARM: imx: (trivial) fix typo and grammar

[Shawn Guo]

On Fri, Sep 02, 2016 at 10:34:40AM +0200, Martin Kaiser wrote:
> Signed-off-by: Martin Kaiser 

Applied, thanks.

> ---
>  arch/arm/mach-imx/hardware.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/hardware.h b/arch/arm/mach-imx/hardware.h
> index a42a6df..90e10cb 100644
> --- a/arch/arm/mach-imx/hardware.h
> +++ b/arch/arm/mach-imx/hardware.h
> @@ -120,7 +120,7 @@
>   .type = _type,  \
>  }
>  
> -/* There's a off-by-one betweem the gpio bank number and the gpiochip */
> +/* There's an off-by-one between the gpio bank number and the gpiochip */
>  /* range e.g. GPIO_1_5 is gpio 5 under linux */
>  #define IMX_GPIO_NR(bank, nr)(((bank) - 1) * 32 + (nr))
>  
> -- 
> 1.7.10.4
> 

[PATCH, v6 0/5] Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

>From 99e428a1808c8ca91ff473d487b52ca5d355d875 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Mon, 5 Sep 2016 10:27:07 +0800
Subject: [PATCH, v6 0/5] Add MediaTek USB3 DRD Driver

These patches introduce the MediaTek USB3 dual-role controller
driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only (xHCI) modes. It works well
with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
tested on MT8173 platform which only contains USB2.0 device IP,
and on MT6290 platform which contains USB3.0 device IP.

Change in v6:
1. handle endianness of GPD and SETUP data
2. remove dummy error log and return suitable error number
3. cancel delay work when deregiseter driver

Change in v5:
1. modify some comments
2. rename some unsuitable variables
3. add reg-names property for host node
4. add USB_MTU3_DEBUG to control debug messages

Change in v4:
1. fix build errors on non-mediatek platforms
2. provide manual dual-role switch via debugfs instead of sysfs

Change in v3:
1. fix some typo error
2. rename mtu3.txt to mt8173-mtu3.txt

Change in v2:
1. modify binding docs according to suggestions
2. modify some comments and remove some dummy blank lines
3. fix memory leakage

Chunfeng Yun (5):
  dt-bindings: mt8173-xhci: support host side of dual-role mode
  dt-bindings: mt8173-mtu3: add devicetree bindings
  usb: xhci-mtk: make IPPC register optional
  usb: Add MediaTek USB3 DRD Driver
  arm64: dts: mediatek: add USB3 DRD driver

 .../devicetree/bindings/usb/mt8173-mtu3.txt|   87 ++
 .../devicetree/bindings/usb/mt8173-xhci.txt|   54 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   46 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   29 +-
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/host/xhci-mtk.c|   36 +-
 drivers/usb/mtu3/Kconfig   |   54 ++
 drivers/usb/mtu3/Makefile  |   19 +
 drivers/usb/mtu3/mtu3.h|  422 ++
 drivers/usb/mtu3/mtu3_core.c   |  871 +++
 drivers/usb/mtu3/mtu3_dr.c |  379 +
 drivers/usb/mtu3/mtu3_dr.h |  108 +++
 drivers/usb/mtu3/mtu3_gadget.c |  731 
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  883 
 drivers/usb/mtu3/mtu3_host.c   |  294 +++
 drivers/usb/mtu3/mtu3_hw_regs.h|  473 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 +++
 drivers/usb/mtu3/mtu3_qmu.c|  599 +
 drivers/usb/mtu3/mtu3_qmu.h|   43 +
 20 files changed, 5603 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

--
1.7.9.5

[PATCH, v6 0/5] Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

>From 99e428a1808c8ca91ff473d487b52ca5d355d875 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Mon, 5 Sep 2016 10:27:07 +0800
Subject: [PATCH, v6 0/5] Add MediaTek USB3 DRD Driver

These patches introduce the MediaTek USB3 dual-role controller
driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only (xHCI) modes. It works well
with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
tested on MT8173 platform which only contains USB2.0 device IP,
and on MT6290 platform which contains USB3.0 device IP.

Change in v6:
1. handle endianness of GPD and SETUP data
2. remove dummy error log and return suitable error number
3. cancel delay work when deregiseter driver

Change in v5:
1. modify some comments
2. rename some unsuitable variables
3. add reg-names property for host node
4. add USB_MTU3_DEBUG to control debug messages

Change in v4:
1. fix build errors on non-mediatek platforms
2. provide manual dual-role switch via debugfs instead of sysfs

Change in v3:
1. fix some typo error
2. rename mtu3.txt to mt8173-mtu3.txt

Change in v2:
1. modify binding docs according to suggestions
2. modify some comments and remove some dummy blank lines
3. fix memory leakage

Chunfeng Yun (5):
  dt-bindings: mt8173-xhci: support host side of dual-role mode
  dt-bindings: mt8173-mtu3: add devicetree bindings
  usb: xhci-mtk: make IPPC register optional
  usb: Add MediaTek USB3 DRD Driver
  arm64: dts: mediatek: add USB3 DRD driver

 .../devicetree/bindings/usb/mt8173-mtu3.txt|   87 ++
 .../devicetree/bindings/usb/mt8173-xhci.txt|   54 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   46 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   29 +-
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/host/xhci-mtk.c|   36 +-
 drivers/usb/mtu3/Kconfig   |   54 ++
 drivers/usb/mtu3/Makefile  |   19 +
 drivers/usb/mtu3/mtu3.h|  422 ++
 drivers/usb/mtu3/mtu3_core.c   |  871 +++
 drivers/usb/mtu3/mtu3_dr.c |  379 +
 drivers/usb/mtu3/mtu3_dr.h |  108 +++
 drivers/usb/mtu3/mtu3_gadget.c |  731 
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  883 
 drivers/usb/mtu3/mtu3_host.c   |  294 +++
 drivers/usb/mtu3/mtu3_hw_regs.h|  473 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 +++
 drivers/usb/mtu3/mtu3_qmu.c|  599 +
 drivers/usb/mtu3/mtu3_qmu.h|   43 +
 20 files changed, 5603 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

--
1.7.9.5

[PATCH v6, 5/5] arm64: dts: mediatek: add USB3 DRD driver

[Chunfeng Yun]

USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |   46 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   29 +
 2 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
 
chosen { };
 
+   extcon_usb: extcon_iddig {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = < 16 GPIO_ACTIVE_HIGH>;
+   };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = < 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   usb_p0_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
 };
 
  {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+   usb_id_pins_float: usb_iddig_pull_up {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   usb_id_pins_ground: usb_iddig_pull_down {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-down;
+   };
+   };
 };
 
  {
@@ -431,12 +460,25 @@
status = "okay";
 };
 
+ {
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   pinctrl-names = "default", "id_float", "id_ground";
+   pinctrl-0 = <_id_pins_float>;
+   pinctrl-1 = <_id_pins_float>;
+   pinctrl-2 = <_id_pins_ground>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
- {
+_host {
vusb33-supply = <_vusb_reg>;
vbus-supply = <_p1_vbus>;
-   mediatek,wakeup-src = <1>;
+   status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..925948a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -668,11 +668,14 @@
status = "disabled";
};
 
-   usb30: usb@1127 {
-   compatible = "mediatek,mt8173-xhci";
-   reg = <0 0x1127 0 0x1000>,
+   ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
  <0 0x11280700 0 0x0100>;
-   interrupts = ;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
 < CLK_PERI_USB0>,
@@ -680,10 +683,22 @@
clock-names = "sys_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
-   phys = <_port0 PHY_TYPE_USB3>,
-  <_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <>;
-   status = "okay";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   reg-names = "mac";
+   interrupts = ;
+   power-domains = < 
MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   status = "disabled";
+   };
};
 
u3phy: usb-phy@1129 {
-- 
1.7.9.5

[PATCH v6, 1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

[Chunfeng Yun]

Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.

Additionally add optional properties of pinctrl for host only mode

Signed-off-by: Chunfeng Yun 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   54 +++-
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..2a930bd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,10 +2,18 @@ MT8173 xHCI
 
 The device node for Mediatek SOC USB3.0 host controller
 
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers,
-   the first one for MAC, the second for IPPC
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
  - interrupts : interrupt used by the controller
  - power-domains : a phandle to USB power domain node to control USB's
mtcmos
@@ -27,12 +35,16 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
  - vbus-supply : reference to the VBUS regulator;
  - usb3-lpm-capable : supports USB3.0 LPM
+ - pinctrl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
 
 Example:
 usb30: usb@1127 {
compatible = "mediatek,mt8173-xhci";
reg = <0 0x1127 0 0x1000>,
  <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
@@ -49,3 +61,41 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <>;
mediatek,wakeup-src = <1>;
 };
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must be
+   "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   reg-names = "mac";
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   usb3-lpm-capable;
+};
-- 
1.7.9.5

Re: [PATCH v2] ARM: dts: sun8i: Add dts file for the NanoPi NEO SBC

[kbuild test robot]

Hi James,

[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on v4.8-rc5 next-20160825]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/James-Pettigrew/ARM-dts-sun8i-Add-dts-file-for-the-NanoPi-NEO-SBC/20160905-085509
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
sunxi/for-next
config: arm-aspeed_g5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts:65.21-22 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v6, 5/5] arm64: dts: mediatek: add USB3 DRD driver

[Chunfeng Yun]

USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |   46 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   29 +
 2 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
 
chosen { };
 
+   extcon_usb: extcon_iddig {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = < 16 GPIO_ACTIVE_HIGH>;
+   };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = < 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   usb_p0_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
 };
 
  {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+   usb_id_pins_float: usb_iddig_pull_up {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   usb_id_pins_ground: usb_iddig_pull_down {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-down;
+   };
+   };
 };
 
  {
@@ -431,12 +460,25 @@
status = "okay";
 };
 
+ {
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   pinctrl-names = "default", "id_float", "id_ground";
+   pinctrl-0 = <_id_pins_float>;
+   pinctrl-1 = <_id_pins_float>;
+   pinctrl-2 = <_id_pins_ground>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
- {
+_host {
vusb33-supply = <_vusb_reg>;
vbus-supply = <_p1_vbus>;
-   mediatek,wakeup-src = <1>;
+   status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..925948a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -668,11 +668,14 @@
status = "disabled";
};
 
-   usb30: usb@1127 {
-   compatible = "mediatek,mt8173-xhci";
-   reg = <0 0x1127 0 0x1000>,
+   ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
  <0 0x11280700 0 0x0100>;
-   interrupts = ;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
 < CLK_PERI_USB0>,
@@ -680,10 +683,22 @@
clock-names = "sys_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
-   phys = <_port0 PHY_TYPE_USB3>,
-  <_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <>;
-   status = "okay";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   reg-names = "mac";
+   interrupts = ;
+   power-domains = < 
MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   status = "disabled";
+   };
};
 
u3phy: usb-phy@1129 {
-- 
1.7.9.5

[PATCH v6, 1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

[Chunfeng Yun]

Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.

Additionally add optional properties of pinctrl for host only mode

Signed-off-by: Chunfeng Yun 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   54 +++-
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..2a930bd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,10 +2,18 @@ MT8173 xHCI
 
 The device node for Mediatek SOC USB3.0 host controller
 
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers,
-   the first one for MAC, the second for IPPC
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
  - interrupts : interrupt used by the controller
  - power-domains : a phandle to USB power domain node to control USB's
mtcmos
@@ -27,12 +35,16 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
  - vbus-supply : reference to the VBUS regulator;
  - usb3-lpm-capable : supports USB3.0 LPM
+ - pinctrl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
 
 Example:
 usb30: usb@1127 {
compatible = "mediatek,mt8173-xhci";
reg = <0 0x1127 0 0x1000>,
  <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
@@ -49,3 +61,41 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <>;
mediatek,wakeup-src = <1>;
 };
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must be
+   "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   reg-names = "mac";
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   usb3-lpm-capable;
+};
-- 
1.7.9.5

Re: [PATCH v2] ARM: dts: sun8i: Add dts file for the NanoPi NEO SBC

[kbuild test robot]

Hi James,

[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on v4.8-rc5 next-20160825]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/James-Pettigrew/ARM-dts-sun8i-Add-dts-file-for-the-NanoPi-NEO-SBC/20160905-085509
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
sunxi/for-next
config: arm-aspeed_g5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts:65.21-22 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v6, 2/5] dt-bindings: mt8173-mtu3: add devicetree bindings

[Chunfeng Yun]

add a DT binding doc for MediaTek USB3 DRD driver

Signed-off-by: Chunfeng Yun 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/usb/mt8173-mtu3.txt|   87 
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
new file mode 100644
index 000..e049d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -0,0 +1,87 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+   depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+   refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+   with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+   parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+   when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+   dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+   "id_float" and "id_ground" are optinal which depends on
+   "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+   "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via debugfs; usually
+   used when receptacle is TYPE-A and also wants to support dual-role
+   mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>,
+< CLK_PERI_USB0>,
+< CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   mediatek,syscon-wakeup = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   reg-names = "mac";
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   status = "disabled";
+   };
+};
-- 
1.7.9.5

[PATCH v6, 2/5] dt-bindings: mt8173-mtu3: add devicetree bindings

[Chunfeng Yun]

add a DT binding doc for MediaTek USB3 DRD driver

Signed-off-by: Chunfeng Yun 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/usb/mt8173-mtu3.txt|   87 
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
new file mode 100644
index 000..e049d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -0,0 +1,87 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+   depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+   refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+   with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+   parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+   when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+   dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+   "id_float" and "id_ground" are optinal which depends on
+   "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+   "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via debugfs; usually
+   used when receptacle is TYPE-A and also wants to support dual-role
+   mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>,
+< CLK_PERI_USB0>,
+< CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   mediatek,syscon-wakeup = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   reg-names = "mac";
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   status = "disabled";
+   };
+};
-- 
1.7.9.5

[PATCH v6, 4/5] usb: Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/mtu3/Kconfig   |   54 +++
 drivers/usb/mtu3/Makefile  |   19 +
 drivers/usb/mtu3/mtu3.h|  422 +
 drivers/usb/mtu3/mtu3_core.c   |  871 +++
 drivers/usb/mtu3/mtu3_dr.c |  379 
 drivers/usb/mtu3/mtu3_dr.h |  108 +
 drivers/usb/mtu3/mtu3_gadget.c |  731 +
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  883 
 drivers/usb/mtu3/mtu3_host.c   |  294 
 drivers/usb/mtu3/mtu3_hw_regs.h|  473 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 
 drivers/usb/mtu3/mtu3_qmu.c|  599 
 drivers/usb/mtu3/mtu3_qmu.h|   43 ++
 15 files changed, 5369 insertions(+)
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..9ca0bf0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig"
 
 endif
 
+source "drivers/usb/mtu3/Kconfig"
+
 source "drivers/usb/musb/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..7791af6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
 obj-$(CONFIG_USB_ISP1760)  += isp1760/
 
 obj-$(CONFIG_USB_MON)  += mon/
+obj-$(CONFIG_USB_MTU3) += mtu3/
 
 obj-$(CONFIG_PCI)  += host/
 obj-$(CONFIG_USB_EHCI_HCD) += host/
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
new file mode 100644
index 000..25cd619
--- /dev/null
+++ b/drivers/usb/mtu3/Kconfig
@@ -0,0 +1,54 @@
+# For MTK USB3.0 IP
+
+config USB_MTU3
+   tristate "MediaTek USB3 Dual Role controller"
+   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
+   help
+ Say Y or M here if your system runs on MediaTek SoCs with
+ Dual Role SuperSpeed USB controller. You can select usb
+ mode as peripheral role or host role, or both.
+
+ If you don't know what this is, please say N.
+
+ Choose M here to compile this driver as a module, and it
+ will be called mtu3.ko.
+
+
+if USB_MTU3
+choice
+   bool "MTU3 Mode Selection"
+   default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET)
+   default USB_MTU3_HOST if (USB && !USB_GADGET)
+   default USB_MTU3_GADGET if (!USB && USB_GADGET)
+
+config USB_MTU3_HOST
+   bool "Host only mode"
+   depends on USB=y || USB=USB_MTU3
+   help
+ Select this when you want to use MTU3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_MTU3_GADGET
+   bool "Gadget only mode"
+   depends on USB_GADGET=y || USB_GADGET=USB_MTU3
+   help
+ Select this when you want to use MTU3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_MTU3_DUAL_ROLE
+   bool "Dual Role mode"
+   depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   help
+ This is the default mode of working of MTU3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+
+config USB_MTU3_DEBUG
+   bool "Enable Debugging Messages"
+   help
+ Say Y here to enable debugging messages in the MTU3 Driver.
+
+endif
diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile
new file mode 100644
index 000..3e17ff7
--- /dev/null
+++ b/drivers/usb/mtu3/Makefile
@@ -0,0 +1,19 @@
+
+ccflags-$(CONFIG_USB_MTU3_DEBUG)   += -DDEBUG
+
+obj-$(CONFIG_USB_MTU3) += mtu3.o
+
+mtu3-y := mtu3_plat.o
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_core.o 

[PATCH v6, 4/5] usb: Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/mtu3/Kconfig   |   54 +++
 drivers/usb/mtu3/Makefile  |   19 +
 drivers/usb/mtu3/mtu3.h|  422 +
 drivers/usb/mtu3/mtu3_core.c   |  871 +++
 drivers/usb/mtu3/mtu3_dr.c |  379 
 drivers/usb/mtu3/mtu3_dr.h |  108 +
 drivers/usb/mtu3/mtu3_gadget.c |  731 +
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  883 
 drivers/usb/mtu3/mtu3_host.c   |  294 
 drivers/usb/mtu3/mtu3_hw_regs.h|  473 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 
 drivers/usb/mtu3/mtu3_qmu.c|  599 
 drivers/usb/mtu3/mtu3_qmu.h|   43 ++
 15 files changed, 5369 insertions(+)
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..9ca0bf0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig"
 
 endif
 
+source "drivers/usb/mtu3/Kconfig"
+
 source "drivers/usb/musb/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..7791af6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
 obj-$(CONFIG_USB_ISP1760)  += isp1760/
 
 obj-$(CONFIG_USB_MON)  += mon/
+obj-$(CONFIG_USB_MTU3) += mtu3/
 
 obj-$(CONFIG_PCI)  += host/
 obj-$(CONFIG_USB_EHCI_HCD) += host/
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
new file mode 100644
index 000..25cd619
--- /dev/null
+++ b/drivers/usb/mtu3/Kconfig
@@ -0,0 +1,54 @@
+# For MTK USB3.0 IP
+
+config USB_MTU3
+   tristate "MediaTek USB3 Dual Role controller"
+   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
+   help
+ Say Y or M here if your system runs on MediaTek SoCs with
+ Dual Role SuperSpeed USB controller. You can select usb
+ mode as peripheral role or host role, or both.
+
+ If you don't know what this is, please say N.
+
+ Choose M here to compile this driver as a module, and it
+ will be called mtu3.ko.
+
+
+if USB_MTU3
+choice
+   bool "MTU3 Mode Selection"
+   default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET)
+   default USB_MTU3_HOST if (USB && !USB_GADGET)
+   default USB_MTU3_GADGET if (!USB && USB_GADGET)
+
+config USB_MTU3_HOST
+   bool "Host only mode"
+   depends on USB=y || USB=USB_MTU3
+   help
+ Select this when you want to use MTU3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_MTU3_GADGET
+   bool "Gadget only mode"
+   depends on USB_GADGET=y || USB_GADGET=USB_MTU3
+   help
+ Select this when you want to use MTU3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_MTU3_DUAL_ROLE
+   bool "Dual Role mode"
+   depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   help
+ This is the default mode of working of MTU3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+
+config USB_MTU3_DEBUG
+   bool "Enable Debugging Messages"
+   help
+ Say Y here to enable debugging messages in the MTU3 Driver.
+
+endif
diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile
new file mode 100644
index 000..3e17ff7
--- /dev/null
+++ b/drivers/usb/mtu3/Makefile
@@ -0,0 +1,19 @@
+
+ccflags-$(CONFIG_USB_MTU3_DEBUG)   += -DDEBUG
+
+obj-$(CONFIG_USB_MTU3) += mtu3.o
+
+mtu3-y := mtu3_plat.o
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_core.o mtu3_gadget_ep0.o mtu3_gadget.o 

[PATCH v6, 3/5] usb: xhci-mtk: make IPPC register optional

[Chunfeng Yun]

Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   36 +---
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..4bf99b9 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power on host ip */
value = readl(>ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(>u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
 
+   if (ippc == NULL)
+   return 0;
+
/* reset whole ip */
value = readl(>ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 /* called during probe() after chip reset completes */
 static int xhci_mtk_setup(struct usb_hcd *hcd)
 {
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
 
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+   }
+
+   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+   if (ret)
+   return ret;
+
+   if (usb_hcd_is_primary_hcd(hcd)) {
+   mtk->num_u3_ports = xhci->num_usb3_ports;
+   mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
 
-   return xhci_gen_setup(hcd, xhci_mtk_quirks);
+   return ret;
 }
 
 static int xhci_mtk_probe(struct platform_device *pdev)
@@ -586,7 +605,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
mtk->hcd = platform_get_drvdata(pdev);
platform_set_drvdata(pdev, mtk);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mac");
hcd->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(hcd->regs)) {
ret = PTR_ERR(hcd->regs);
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   mtk->ippc_regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(mtk->ippc_regs)) {
-   ret = PTR_ERR(mtk->ippc_regs);
-   goto put_usb2_hcd;
+   mtk->ippc_regs = NULL;
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ippc");
+   if (res) {  /* ippc register is optional */
+   mtk->ippc_regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(mtk->ippc_regs)) {
+   ret = PTR_ERR(mtk->ippc_regs);
+   goto put_usb2_hcd;
+   }
}
 
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
-- 
1.7.9.5

[PATCH v6, 3/5] usb: xhci-mtk: make IPPC register optional

[Chunfeng Yun]

Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   36 +---
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..4bf99b9 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power on host ip */
value = readl(>ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(>u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
 
+   if (ippc == NULL)
+   return 0;
+
/* reset whole ip */
value = readl(>ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 /* called during probe() after chip reset completes */
 static int xhci_mtk_setup(struct usb_hcd *hcd)
 {
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
 
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+   }
+
+   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+   if (ret)
+   return ret;
+
+   if (usb_hcd_is_primary_hcd(hcd)) {
+   mtk->num_u3_ports = xhci->num_usb3_ports;
+   mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
 
-   return xhci_gen_setup(hcd, xhci_mtk_quirks);
+   return ret;
 }
 
 static int xhci_mtk_probe(struct platform_device *pdev)
@@ -586,7 +605,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
mtk->hcd = platform_get_drvdata(pdev);
platform_set_drvdata(pdev, mtk);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mac");
hcd->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(hcd->regs)) {
ret = PTR_ERR(hcd->regs);
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   mtk->ippc_regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(mtk->ippc_regs)) {
-   ret = PTR_ERR(mtk->ippc_regs);
-   goto put_usb2_hcd;
+   mtk->ippc_regs = NULL;
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ippc");
+   if (res) {  /* ippc register is optional */
+   mtk->ippc_regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(mtk->ippc_regs)) {
+   ret = PTR_ERR(mtk->ippc_regs);
+   goto put_usb2_hcd;
+   }
}
 
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
-- 
1.7.9.5

Re: [RFC PATCH V5 5/5] PCI: thunder-pem: Support quirky configuration space access for ACPI based PCI host controller

[Bjorn Helgaas]

On Mon, Aug 08, 2016 at 03:05:41PM +0200, Tomasz Nowicki wrote:
> Add infrastructure to support ThunderX PEM specific PCI configuration space
> access for ACPI based PCI host controller. This involves:
> 1. New initialization call thunder_pem_cfg_init() to create configuration
> space mapping based on hardcoded range addresses
> 2. thunder_pem_init() ACPI extension to obtain hardcoded addresses for
> PEM specific register ranges
> 3. New quirk entry (for common quirk array) which identifies platform and
> calls thunder_pem_cfg_init() from [1]

Is it possible to split this up a little bit?  I *hope* most quirks
aren't as complicated as all this.  It'd be nice to make the actual
quirk patches as small as possible so they can be easily copied and
adapted.

Another question below...

> Signed-off-by: Tomasz Nowicki 
> ---
>  drivers/pci/host/mcfg-quirks.c |  7 +++
>  drivers/pci/host/mcfg-quirks.h |  4 ++
>  drivers/pci/host/pci-thunder-pem.c | 96 
> --
>  3 files changed, 94 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
> index aa9907b..2993a72 100644
> --- a/drivers/pci/host/mcfg-quirks.c
> +++ b/drivers/pci/host/mcfg-quirks.c
> @@ -44,6 +44,13 @@ struct pci_cfg_fixup {
>  
>  static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
>  /*   { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> + /* Pass2.0 */
> + { "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(4, 9), MCFG_BUS_ANY, NULL,
> +   thunder_pem_cfg_init },
> + { "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY, NULL,
> +   thunder_pem_cfg_init },
> +#endif
>  };
>  
>  static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
> diff --git a/drivers/pci/host/mcfg-quirks.h b/drivers/pci/host/mcfg-quirks.h
> index 45cbd16..411c667 100644
> --- a/drivers/pci/host/mcfg-quirks.h
> +++ b/drivers/pci/host/mcfg-quirks.h
> @@ -16,5 +16,9 @@
>  #define __MCFG_QUIRKS_H__
>  
>  /* MCFG quirks initialize call list */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> +struct pci_config_window *
> +thunder_pem_cfg_init(struct acpi_pci_root *root, struct pci_ops *ops);
> +#endif
>  
>  #endif /* __MCFG_QUIRKS_H__ */
> diff --git a/drivers/pci/host/pci-thunder-pem.c 
> b/drivers/pci/host/pci-thunder-pem.c
> index 6abaf80..3f06e49 100644
> --- a/drivers/pci/host/pci-thunder-pem.c
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -18,9 +18,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +#include "mcfg-quirks.h"
> +
>  #define PEM_CFG_WR 0x28
>  #define PEM_CFG_RD 0x30
>  
> @@ -284,6 +287,37 @@ static int thunder_pem_config_write(struct pci_bus *bus, 
> unsigned int devfn,
>   return pci_generic_config_write(bus, devfn, where, size, val);
>  }
>  
> +#ifdef CONFIG_ACPI
> +
> +static struct resource thunder_pem_reg_res[] = {
> + [4] = DEFINE_RES_MEM(0x87e0c000UL, SZ_16M),
> + [5] = DEFINE_RES_MEM(0x87e0c100UL, SZ_16M),
> + [6] = DEFINE_RES_MEM(0x87e0c200UL, SZ_16M),
> + [7] = DEFINE_RES_MEM(0x87e0c300UL, SZ_16M),
> + [8] = DEFINE_RES_MEM(0x87e0c400UL, SZ_16M),
> + [9] = DEFINE_RES_MEM(0x87e0c500UL, SZ_16M),
> + [14] = DEFINE_RES_MEM(0x97e0c000UL, SZ_16M),
> + [15] = DEFINE_RES_MEM(0x97e0c100UL, SZ_16M),
> + [16] = DEFINE_RES_MEM(0x97e0c200UL, SZ_16M),
> + [17] = DEFINE_RES_MEM(0x97e0c300UL, SZ_16M),
> + [18] = DEFINE_RES_MEM(0x97e0c400UL, SZ_16M),
> + [19] = DEFINE_RES_MEM(0x97e0c500UL, SZ_16M),
> +};
> +
> +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
> +{
> + struct acpi_device *adev = to_acpi_device(cfg->parent);
> + struct acpi_pci_root *root = acpi_driver_data(adev);
> +
> + return _pem_reg_res[root->segment];
> +}
> +#else
> +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
> +{
> + return NULL;
> +}
> +#endif
> +
>  static int thunder_pem_init(struct pci_config_window *cfg)
>  {
>   struct device *dev = cfg->parent;
> @@ -292,24 +326,24 @@ static int thunder_pem_init(struct pci_config_window 
> *cfg)
>   struct thunder_pem_pci *pem_pci;
>   struct platform_device *pdev;
>  
> - /* Only OF support for now */
> - if (!dev->of_node)
> - return -EINVAL;
> -
>   pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
>   if (!pem_pci)
>   return -ENOMEM;
>  
> - pdev = to_platform_device(dev);
> -
> - /*
> -  * The second register range is the PEM bridge to the PCIe
> -  * bus.  It has a different config access method than those
> -  * devices behind the bridge.
> -  */
> - res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (acpi_disabled) {
> + pdev = to_platform_device(dev);
> +
> + /*
> +  * The second register 

Re: [RFC PATCH V5 5/5] PCI: thunder-pem: Support quirky configuration space access for ACPI based PCI host controller

[Bjorn Helgaas]

On Mon, Aug 08, 2016 at 03:05:41PM +0200, Tomasz Nowicki wrote:
> Add infrastructure to support ThunderX PEM specific PCI configuration space
> access for ACPI based PCI host controller. This involves:
> 1. New initialization call thunder_pem_cfg_init() to create configuration
> space mapping based on hardcoded range addresses
> 2. thunder_pem_init() ACPI extension to obtain hardcoded addresses for
> PEM specific register ranges
> 3. New quirk entry (for common quirk array) which identifies platform and
> calls thunder_pem_cfg_init() from [1]

Is it possible to split this up a little bit?  I *hope* most quirks
aren't as complicated as all this.  It'd be nice to make the actual
quirk patches as small as possible so they can be easily copied and
adapted.

Another question below...

> Signed-off-by: Tomasz Nowicki 
> ---
>  drivers/pci/host/mcfg-quirks.c |  7 +++
>  drivers/pci/host/mcfg-quirks.h |  4 ++
>  drivers/pci/host/pci-thunder-pem.c | 96 
> --
>  3 files changed, 94 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
> index aa9907b..2993a72 100644
> --- a/drivers/pci/host/mcfg-quirks.c
> +++ b/drivers/pci/host/mcfg-quirks.c
> @@ -44,6 +44,13 @@ struct pci_cfg_fixup {
>  
>  static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
>  /*   { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> + /* Pass2.0 */
> + { "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(4, 9), MCFG_BUS_ANY, NULL,
> +   thunder_pem_cfg_init },
> + { "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY, NULL,
> +   thunder_pem_cfg_init },
> +#endif
>  };
>  
>  static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
> diff --git a/drivers/pci/host/mcfg-quirks.h b/drivers/pci/host/mcfg-quirks.h
> index 45cbd16..411c667 100644
> --- a/drivers/pci/host/mcfg-quirks.h
> +++ b/drivers/pci/host/mcfg-quirks.h
> @@ -16,5 +16,9 @@
>  #define __MCFG_QUIRKS_H__
>  
>  /* MCFG quirks initialize call list */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> +struct pci_config_window *
> +thunder_pem_cfg_init(struct acpi_pci_root *root, struct pci_ops *ops);
> +#endif
>  
>  #endif /* __MCFG_QUIRKS_H__ */
> diff --git a/drivers/pci/host/pci-thunder-pem.c 
> b/drivers/pci/host/pci-thunder-pem.c
> index 6abaf80..3f06e49 100644
> --- a/drivers/pci/host/pci-thunder-pem.c
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -18,9 +18,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +#include "mcfg-quirks.h"
> +
>  #define PEM_CFG_WR 0x28
>  #define PEM_CFG_RD 0x30
>  
> @@ -284,6 +287,37 @@ static int thunder_pem_config_write(struct pci_bus *bus, 
> unsigned int devfn,
>   return pci_generic_config_write(bus, devfn, where, size, val);
>  }
>  
> +#ifdef CONFIG_ACPI
> +
> +static struct resource thunder_pem_reg_res[] = {
> + [4] = DEFINE_RES_MEM(0x87e0c000UL, SZ_16M),
> + [5] = DEFINE_RES_MEM(0x87e0c100UL, SZ_16M),
> + [6] = DEFINE_RES_MEM(0x87e0c200UL, SZ_16M),
> + [7] = DEFINE_RES_MEM(0x87e0c300UL, SZ_16M),
> + [8] = DEFINE_RES_MEM(0x87e0c400UL, SZ_16M),
> + [9] = DEFINE_RES_MEM(0x87e0c500UL, SZ_16M),
> + [14] = DEFINE_RES_MEM(0x97e0c000UL, SZ_16M),
> + [15] = DEFINE_RES_MEM(0x97e0c100UL, SZ_16M),
> + [16] = DEFINE_RES_MEM(0x97e0c200UL, SZ_16M),
> + [17] = DEFINE_RES_MEM(0x97e0c300UL, SZ_16M),
> + [18] = DEFINE_RES_MEM(0x97e0c400UL, SZ_16M),
> + [19] = DEFINE_RES_MEM(0x97e0c500UL, SZ_16M),
> +};
> +
> +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
> +{
> + struct acpi_device *adev = to_acpi_device(cfg->parent);
> + struct acpi_pci_root *root = acpi_driver_data(adev);
> +
> + return _pem_reg_res[root->segment];
> +}
> +#else
> +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
> +{
> + return NULL;
> +}
> +#endif
> +
>  static int thunder_pem_init(struct pci_config_window *cfg)
>  {
>   struct device *dev = cfg->parent;
> @@ -292,24 +326,24 @@ static int thunder_pem_init(struct pci_config_window 
> *cfg)
>   struct thunder_pem_pci *pem_pci;
>   struct platform_device *pdev;
>  
> - /* Only OF support for now */
> - if (!dev->of_node)
> - return -EINVAL;
> -
>   pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
>   if (!pem_pci)
>   return -ENOMEM;
>  
> - pdev = to_platform_device(dev);
> -
> - /*
> -  * The second register range is the PEM bridge to the PCIe
> -  * bus.  It has a different config access method than those
> -  * devices behind the bridge.
> -  */
> - res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (acpi_disabled) {
> + pdev = to_platform_device(dev);
> +
> + /*
> +  * The second register range is the PEM 

Re: [PATCH v4] ARM: imx: Added perf functionality to mmdc driver

[Shawn Guo]

On Wed, Aug 31, 2016 at 12:00:29PM -0500, Zhengyu Shen wrote:
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
> MMDC provides registers for performance counters which read via this
> driver to help debug memory throughput and similar issues.
> 
> $ perf stat -a -e 
> mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/
>  dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
> 
>  898021787  mmdc/busy-cycles/
>   14819600  mmdc/read-accesses/
> 471.30 MB   mmdc/read-bytes/
> 2815419216  mmdc/total-cycles/
>   13367354  mmdc/write-accesses/
> 427.76 MB   mmdc/write-bytes/
> 
>5.334757334 seconds time elapsed
> 
> Signed-off-by: Zhengyu Shen 
> Signed-off-by: Frank Li 

I'm fine with this version, but still want a Reviewed-by tag from Mark
to apply the patch.

Shawn

Re: [PATCH v4] ARM: imx: Added perf functionality to mmdc driver

[Shawn Guo]

On Wed, Aug 31, 2016 at 12:00:29PM -0500, Zhengyu Shen wrote:
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
> MMDC provides registers for performance counters which read via this
> driver to help debug memory throughput and similar issues.
> 
> $ perf stat -a -e 
> mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/
>  dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
> 
>  898021787  mmdc/busy-cycles/
>   14819600  mmdc/read-accesses/
> 471.30 MB   mmdc/read-bytes/
> 2815419216  mmdc/total-cycles/
>   13367354  mmdc/write-accesses/
> 427.76 MB   mmdc/write-bytes/
> 
>5.334757334 seconds time elapsed
> 
> Signed-off-by: Zhengyu Shen 
> Signed-off-by: Frank Li 

I'm fine with this version, but still want a Reviewed-by tag from Mark
to apply the patch.

Shawn

Re: [kbuild-all] video-vga.c:undefined reference to `__gcov_init'

[Fengguang Wu]

Hi Joe,

On Sun, Sep 04, 2016 at 07:18:22PM -0700, Joe Perches wrote:

On Mon, 2016-09-05 at 10:13 +0800, kbuild test robot wrote:

Hi Joe,


Hi Fengguang


FYI, the error/warning still remains.


Is this really my responsibility?
I don't think so.
I didn't submit this patch to stable.
I don't know nor care really who did,
but I think the robot should ping the
stable submitter.


Sorry for the noise! This particular commit are obviously attributed
too many irrelevant errors. I'll just drop reports for this commit.

In this case it's not relevant to the stable maintainers?

Fengguang


tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c6935931c1894ff857616ff8549b61236a19148f
commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the 
various compiler-gcc[345].h files
date:   1 year, 2 months ago
config: x86_64-rhel_gcov (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout cb984d101b30eb7478d32df56a0023e4603cba7f
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/realmode/rm/video-vga.o:(.data+0x150): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-vga.o: In function 
`_GLOBAL__sub_I_65535_0_vga_crtc':
>
> >
> > video-vga.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/wakemain.o:(.data+0x70): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/wakemain.o: In function `_GLOBAL__sub_I_65535_0_main':
>
> >
> > wakemain.c:(.text.startup+0x1f4): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/video-mode.o:(.data+0x90): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-mode.o: In function 
`_GLOBAL__sub_I_65535_0_probe_cards':
>
> >
> > video-mode.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/regs.o:(.data+0x30): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/regs.o: In function `_GLOBAL__sub_I_65535_0_initregs':
>
> >
> > regs.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/video-vesa.o:(.data+0x70): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-vesa.o: In function 
`_GLOBAL__sub_I_65535_0_video_vesa.c':
>
> >
> > video-vesa.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/video-bios.o:(.data+0x90): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-bios.o: In function 
`_GLOBAL__sub_I_65535_0_video_bios.c':
>
> >
> > video-bios.c:(.text.startup+0x7): undefined reference to `__gcov_init'
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

___
kbuild-all mailing list
kbuild-...@lists.01.org
https://lists.01.org/mailman/listinfo/kbuild-all

Re: [kbuild-all] video-vga.c:undefined reference to `__gcov_init'

[Fengguang Wu]

Hi Joe,

On Sun, Sep 04, 2016 at 07:18:22PM -0700, Joe Perches wrote:

On Mon, 2016-09-05 at 10:13 +0800, kbuild test robot wrote:

Hi Joe,


Hi Fengguang


FYI, the error/warning still remains.


Is this really my responsibility?
I don't think so.
I didn't submit this patch to stable.
I don't know nor care really who did,
but I think the robot should ping the
stable submitter.


Sorry for the noise! This particular commit are obviously attributed
too many irrelevant errors. I'll just drop reports for this commit.

In this case it's not relevant to the stable maintainers?

Fengguang


tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c6935931c1894ff857616ff8549b61236a19148f
commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the 
various compiler-gcc[345].h files
date:   1 year, 2 months ago
config: x86_64-rhel_gcov (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout cb984d101b30eb7478d32df56a0023e4603cba7f
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/realmode/rm/video-vga.o:(.data+0x150): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-vga.o: In function 
`_GLOBAL__sub_I_65535_0_vga_crtc':
>
> >
> > video-vga.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/wakemain.o:(.data+0x70): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/wakemain.o: In function `_GLOBAL__sub_I_65535_0_main':
>
> >
> > wakemain.c:(.text.startup+0x1f4): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/video-mode.o:(.data+0x90): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-mode.o: In function 
`_GLOBAL__sub_I_65535_0_probe_cards':
>
> >
> > video-mode.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/regs.o:(.data+0x30): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/regs.o: In function `_GLOBAL__sub_I_65535_0_initregs':
>
> >
> > regs.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/video-vesa.o:(.data+0x70): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-vesa.o: In function 
`_GLOBAL__sub_I_65535_0_video_vesa.c':
>
> >
> > video-vesa.c:(.text.startup+0x7): undefined reference to `__gcov_init'
   arch/x86/realmode/rm/video-bios.o:(.data+0x90): undefined reference to 
`__gcov_merge_add'
   arch/x86/realmode/rm/video-bios.o: In function 
`_GLOBAL__sub_I_65535_0_video_bios.c':
>
> >
> > video-bios.c:(.text.startup+0x7): undefined reference to `__gcov_init'
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

___
kbuild-all mailing list
kbuild-...@lists.01.org
https://lists.01.org/mailman/listinfo/kbuild-all