Re: [PATCH 1/2] cpufreq: powernv: Adding fast_switch for schedutil

[Akshay Adiga]

Thanks Viresh for taking a look at it.

I will make the mentioned changes in the next version of the patch.


Regards

Akshay Adiga


On 11/04/2016 12:03 PM, Viresh Kumar wrote:

On 04-11-16, 10:57, Akshay Adiga wrote:

Adding fast_switch which does light weight operation to
set the desired pstate.

Signed-off-by: Akshay Adiga 
---
  drivers/cpufreq/powernv-cpufreq.c | 22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index d3ffde8..09a0496 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -752,9 +752,12 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
spin_lock_init(>gpstate_lock);
ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
  
-	if (ret < 0)

+   if (ret < 0) {
kfree(policy->driver_data);
+   return ret;
+   }
  
+	policy->fast_switch_possible = true;

return ret;
  }
  
@@ -897,6 +900,22 @@ static void powernv_cpufreq_stop_cpu(struct cpufreq_policy *policy)

del_timer_sync(>timer);
  }
  
+static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,

+   unsigned int target_freq)
+{
+   int index;
+   struct powernv_smp_call_data freq_data;
+
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+   if (index < 0 || index >= powernv_pstate_info.nr_pstates)
+   return CPUFREQ_ENTRY_INVALID;

I don't think such a check is required at all. It wouldn't happen without a BUG
in kernel.

+   freq_data.pstate_id = powernv_freqs[index].driver_data;
+   freq_data.gpstate_id = powernv_freqs[index].driver_data;
+   set_pstate(_data);
+
+   return powernv_freqs[index].frequency;
+}
+
  static struct cpufreq_driver powernv_cpufreq_driver = {
.name   = "powernv-cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -904,6 +923,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.exit   = powernv_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = powernv_cpufreq_target_index,
+   .fast_switch= powernv_fast_switch,
.get= powernv_cpufreq_get,
.stop_cpu   = powernv_cpufreq_stop_cpu,
.attr   = powernv_cpu_freq_attr,
--
2.7.4

Re: [PATCH 1/2] cpufreq: powernv: Adding fast_switch for schedutil

[Akshay Adiga]

Thanks Viresh for taking a look at it.

I will make the mentioned changes in the next version of the patch.


Regards

Akshay Adiga


On 11/04/2016 12:03 PM, Viresh Kumar wrote:

On 04-11-16, 10:57, Akshay Adiga wrote:

Adding fast_switch which does light weight operation to
set the desired pstate.

Signed-off-by: Akshay Adiga 
---
  drivers/cpufreq/powernv-cpufreq.c | 22 +-
  1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index d3ffde8..09a0496 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -752,9 +752,12 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
spin_lock_init(>gpstate_lock);
ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
  
-	if (ret < 0)

+   if (ret < 0) {
kfree(policy->driver_data);
+   return ret;
+   }
  
+	policy->fast_switch_possible = true;

return ret;
  }
  
@@ -897,6 +900,22 @@ static void powernv_cpufreq_stop_cpu(struct cpufreq_policy *policy)

del_timer_sync(>timer);
  }
  
+static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,

+   unsigned int target_freq)
+{
+   int index;
+   struct powernv_smp_call_data freq_data;
+
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+   if (index < 0 || index >= powernv_pstate_info.nr_pstates)
+   return CPUFREQ_ENTRY_INVALID;

I don't think such a check is required at all. It wouldn't happen without a BUG
in kernel.

+   freq_data.pstate_id = powernv_freqs[index].driver_data;
+   freq_data.gpstate_id = powernv_freqs[index].driver_data;
+   set_pstate(_data);
+
+   return powernv_freqs[index].frequency;
+}
+
  static struct cpufreq_driver powernv_cpufreq_driver = {
.name   = "powernv-cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -904,6 +923,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.exit   = powernv_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = powernv_cpufreq_target_index,
+   .fast_switch= powernv_fast_switch,
.get= powernv_cpufreq_get,
.stop_cpu   = powernv_cpufreq_stop_cpu,
.attr   = powernv_cpu_freq_attr,
--
2.7.4

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

[Linus Walleij]

On Wed, Nov 2, 2016 at 11:48 AM, Suresh Mangipudi  wrote:

> Add GPIO driver for T186 based platforms.
> Adds support for MAIN and AON GPIO's from T186.
>
> Signed-off-by: Suresh Mangipudi 

Stephen/Thierry/Alexandre:
Can I get your review on this Tegra thing?

Yours,
Linus Walleij

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

[Linus Walleij]

On Wed, Nov 2, 2016 at 11:48 AM, Suresh Mangipudi  wrote:

> Add GPIO driver for T186 based platforms.
> Adds support for MAIN and AON GPIO's from T186.
>
> Signed-off-by: Suresh Mangipudi 

Stephen/Thierry/Alexandre:
Can I get your review on this Tegra thing?

Yours,
Linus Walleij

[PATCH] ARC: [plat-eznps] remove IPI clear from SMP operations

[Noam Camus]

From: Noam Camus 

Generic IRQ mechanism is already acknowledge the IPI IRQ.
Doing this once more time in IPI handler is not needed.

Signed-off-by: Noam Camus 
---
 arch/arc/plat-eznps/smp.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arc/plat-eznps/smp.c b/arch/arc/plat-eznps/smp.c
index 5e901f8..56a4c85 100644
--- a/arch/arc/plat-eznps/smp.c
+++ b/arch/arc/plat-eznps/smp.c
@@ -140,16 +140,10 @@ static void eznps_init_per_cpu(int cpu)
mtm_enable_core(cpu);
 }
 
-static void eznps_ipi_clear(int irq)
-{
-   write_aux_reg(CTOP_AUX_IACK, 1 << irq);
-}
-
 struct plat_smp_ops plat_smp_ops = {
.info   = smp_cpuinfo_buf,
.init_early_smp = eznps_init_cpumasks,
.cpu_kick   = eznps_smp_wakeup_cpu,
.ipi_send   = eznps_ipi_send,
.init_per_cpu   = eznps_init_per_cpu,
-   .ipi_clear  = eznps_ipi_clear,
 };
-- 
1.7.1

[PATCH] ARC: [plat-eznps] remove IPI clear from SMP operations

[Noam Camus]

From: Noam Camus 

Generic IRQ mechanism is already acknowledge the IPI IRQ.
Doing this once more time in IPI handler is not needed.

Signed-off-by: Noam Camus 
---
 arch/arc/plat-eznps/smp.c |6 --
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arc/plat-eznps/smp.c b/arch/arc/plat-eznps/smp.c
index 5e901f8..56a4c85 100644
--- a/arch/arc/plat-eznps/smp.c
+++ b/arch/arc/plat-eznps/smp.c
@@ -140,16 +140,10 @@ static void eznps_init_per_cpu(int cpu)
mtm_enable_core(cpu);
 }
 
-static void eznps_ipi_clear(int irq)
-{
-   write_aux_reg(CTOP_AUX_IACK, 1 << irq);
-}
-
 struct plat_smp_ops plat_smp_ops = {
.info   = smp_cpuinfo_buf,
.init_early_smp = eznps_init_cpumasks,
.cpu_kick   = eznps_smp_wakeup_cpu,
.ipi_send   = eznps_ipi_send,
.init_per_cpu   = eznps_init_per_cpu,
-   .ipi_clear  = eznps_ipi_clear,
 };
-- 
1.7.1

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

On 2016/11/7 15:44, Chen Feng wrote:
> On 2016/11/7 15:27, Joonsoo Kim wrote:
>> On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
>>>
>>>
>>> On 2016/11/7 14:15, Joonsoo Kim wrote:
 On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> Hello, I hava a question on cma zone.
>
> When we have cma zone, cma zone will be the highest zone of system.
>
> In android system, the most memory allocator is ION. Media system will
> alloc unmovable memory from it.
>
> On low memory scene, will the CMA zone always do balance?

 Allocation request for low zone (normal zone) would not cause CMA zone
 to be balanced since it isn't helpful.

>>> Yes. But the cma zone will run out soon. And it always need to do balance.
>>>
>>> How about use migrate cma before movable and let cma type to fallback 
>>> movable.
>>>
>>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
>>
>> ZONE_CMA approach will act like as your solution. Could you elaborate
>> more on the problem of zone approach?
>>
> 
> The ZONE approach is that makes cma pages in a zone. It can cause a higher 
> swapin/out
> than use migrate cma first.
> 
> The higher swapin/out may have a performance effect to application. The 
> application may
> use too much time swapin memory.
> 
> You can see my tested result attached for detail. And the baseline is result 
> of [1].
> 
> 
My test case is run 60 applications and alloc 512MB ION memory.

Repeat this action 50 times

> [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
>> Thanks.
>>
>> .
>>

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

On 2016/11/7 15:44, Chen Feng wrote:
> On 2016/11/7 15:27, Joonsoo Kim wrote:
>> On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
>>>
>>>
>>> On 2016/11/7 14:15, Joonsoo Kim wrote:
 On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> Hello, I hava a question on cma zone.
>
> When we have cma zone, cma zone will be the highest zone of system.
>
> In android system, the most memory allocator is ION. Media system will
> alloc unmovable memory from it.
>
> On low memory scene, will the CMA zone always do balance?

 Allocation request for low zone (normal zone) would not cause CMA zone
 to be balanced since it isn't helpful.

>>> Yes. But the cma zone will run out soon. And it always need to do balance.
>>>
>>> How about use migrate cma before movable and let cma type to fallback 
>>> movable.
>>>
>>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
>>
>> ZONE_CMA approach will act like as your solution. Could you elaborate
>> more on the problem of zone approach?
>>
> 
> The ZONE approach is that makes cma pages in a zone. It can cause a higher 
> swapin/out
> than use migrate cma first.
> 
> The higher swapin/out may have a performance effect to application. The 
> application may
> use too much time swapin memory.
> 
> You can see my tested result attached for detail. And the baseline is result 
> of [1].
> 
> 
My test case is run 60 applications and alloc 512MB ION memory.

Repeat this action 50 times

> [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
>> Thanks.
>>
>> .
>>

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

On 2016/11/7 15:27, Joonsoo Kim wrote:
> On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
>>
>>
>> On 2016/11/7 14:15, Joonsoo Kim wrote:
>>> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
 Hello, I hava a question on cma zone.

 When we have cma zone, cma zone will be the highest zone of system.

 In android system, the most memory allocator is ION. Media system will
 alloc unmovable memory from it.

 On low memory scene, will the CMA zone always do balance?
>>>
>>> Allocation request for low zone (normal zone) would not cause CMA zone
>>> to be balanced since it isn't helpful.
>>>
>> Yes. But the cma zone will run out soon. And it always need to do balance.
>>
>> How about use migrate cma before movable and let cma type to fallback 
>> movable.
>>
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
> 
> ZONE_CMA approach will act like as your solution. Could you elaborate
> more on the problem of zone approach?
> 

The ZONE approach is that makes cma pages in a zone. It can cause a higher 
swapin/out
than use migrate cma first.

The higher swapin/out may have a performance effect to application. The 
application may
use too much time swapin memory.

You can see my tested result attached for detail. And the baseline is result of 
[1].


[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
> Thanks.
> 
> .
> 

Re: [PATCH v2] drm: move allocation out of drm_get_format_name()

[Christian König]

Am 07.11.2016 um 01:48 schrieb Eric Engestrom:

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

 drm: make drm_get_format_name thread-safe

 Signed-off-by: Eric Engestrom 
 [danvet: Clarify that the returned pointer must be freed with
 kfree().]
 Signed-off-by: Daniel Vetter 

Cc: Rob Clark 
Cc: Christian König 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 

Acked-by: Christian König .


---

v2: use single-field struct instead of typedef to let the compiler
 enforce the type (Christian König)

---
  include/drm/drm_fourcc.h| 10 +-
  drivers/gpu/drm/drm_fourcc.c| 14 +++--
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
  drivers/gpu/drm/drm_atomic.c|  7 +++--
  drivers/gpu/drm/drm_crtc.c  |  7 +++--
  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
  drivers/gpu/drm/drm_plane.c |  7 +++--
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
  drivers/gpu/drm/i915/intel_display.c| 41 ++---
  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
  17 files changed, 80 insertions(+), 86 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..4b03ca0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
  };
  
+/**

+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
  const struct drm_format_info *__drm_format_info(u32 format);
  const struct drm_format_info *drm_format_info(u32 format);
  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
  int drm_format_vert_chroma_subsampling(uint32_t format);
  int drm_format_plane_width(int width, uint32_t format, int plane);
  int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
  
  #endif /* __DRM_FOURCC_H__ */

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..99b0b60 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
  
  /**

- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
   * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
   */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
  {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
  
-	return buf;

+   return buf->str;
  }
  EXPORT_SYMBOL(drm_get_format_name);
  
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c

index 199d3f7..2924cdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   struct drm_format_name_buf format_name;
  
  	/* no fb bound */

if (!atomic && !crtc->primary->fb) {
@@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
+ 

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

On 2016/11/7 15:27, Joonsoo Kim wrote:
> On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
>>
>>
>> On 2016/11/7 14:15, Joonsoo Kim wrote:
>>> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
 Hello, I hava a question on cma zone.

 When we have cma zone, cma zone will be the highest zone of system.

 In android system, the most memory allocator is ION. Media system will
 alloc unmovable memory from it.

 On low memory scene, will the CMA zone always do balance?
>>>
>>> Allocation request for low zone (normal zone) would not cause CMA zone
>>> to be balanced since it isn't helpful.
>>>
>> Yes. But the cma zone will run out soon. And it always need to do balance.
>>
>> How about use migrate cma before movable and let cma type to fallback 
>> movable.
>>
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
> 
> ZONE_CMA approach will act like as your solution. Could you elaborate
> more on the problem of zone approach?
> 

The ZONE approach is that makes cma pages in a zone. It can cause a higher 
swapin/out
than use migrate cma first.

The higher swapin/out may have a performance effect to application. The 
application may
use too much time swapin memory.

You can see my tested result attached for detail. And the baseline is result of 
[1].


[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html
> Thanks.
> 
> .
> 

Re: [PATCH v2] drm: move allocation out of drm_get_format_name()

[Christian König]

Am 07.11.2016 um 01:48 schrieb Eric Engestrom:

Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07

 drm: make drm_get_format_name thread-safe

 Signed-off-by: Eric Engestrom 
 [danvet: Clarify that the returned pointer must be freed with
 kfree().]
 Signed-off-by: Daniel Vetter 

Cc: Rob Clark 
Cc: Christian König 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 

Acked-by: Christian König .


---

v2: use single-field struct instead of typedef to let the compiler
 enforce the type (Christian König)

---
  include/drm/drm_fourcc.h| 10 +-
  drivers/gpu/drm/drm_fourcc.c| 14 +++--
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
  drivers/gpu/drm/drm_atomic.c|  7 +++--
  drivers/gpu/drm/drm_crtc.c  |  7 +++--
  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
  drivers/gpu/drm/drm_plane.c |  7 +++--
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
  drivers/gpu/drm/i915/intel_display.c| 41 ++---
  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
  17 files changed, 80 insertions(+), 86 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..4b03ca0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
  };
  
+/**

+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
  const struct drm_format_info *__drm_format_info(u32 format);
  const struct drm_format_info *drm_format_info(u32 format);
  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
  int drm_format_vert_chroma_subsampling(uint32_t format);
  int drm_format_plane_width(int width, uint32_t format, int plane);
  int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
  
  #endif /* __DRM_FOURCC_H__ */

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..99b0b60 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
  
  /**

- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
   * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
   */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
  {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
  
-	return buf;

+   return buf->str;
  }
  EXPORT_SYMBOL(drm_get_format_name);
  
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c

index 199d3f7..2924cdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
u32 tmp, viewport_w, viewport_h;
int r;
bool bypass_lut = false;
-   char *format_name;
+   struct drm_format_name_buf format_name;
  
  	/* no fb bound */

if (!atomic && !crtc->primary->fb) {
@@ -2144,9 +2144,8 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
*crtc,
bypass_lut = true;
break;
default:
-   format_name = drm_get_format_name(target_fb->pixel_format);
-   DRM_ERROR("Unsupported screen format %s\n", format_name);
+   DRM_ERROR("Unsupported screen format %s\n",
+ drm_get_format_name(target_fb->pixel_format, 
_name));
-   

[PATCH v2 1/2] cpufreq: powernv: Adding fast_switch for schedutil

[Akshay Adiga]

Adding fast_switch which does light weight operation to set the desired
pstate. Both global and local pstates are set to the same desired pstate.

Signed-off-by: Akshay Adiga 
---
Changes from v1 :
- Removed unnecessary check for index out of bound.

 drivers/cpufreq/powernv-cpufreq.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index d3ffde8..4a4380d 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -752,9 +752,12 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
spin_lock_init(>gpstate_lock);
ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
 
-   if (ret < 0)
+   if (ret < 0) {
kfree(policy->driver_data);
+   return ret;
+   }
 
+   policy->fast_switch_possible = true;
return ret;
 }
 
@@ -897,6 +900,20 @@ static void powernv_cpufreq_stop_cpu(struct cpufreq_policy 
*policy)
del_timer_sync(>timer);
 }
 
+static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   int index;
+   struct powernv_smp_call_data freq_data;
+
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+   freq_data.pstate_id = powernv_freqs[index].driver_data;
+   freq_data.gpstate_id = powernv_freqs[index].driver_data;
+   set_pstate(_data);
+
+   return powernv_freqs[index].frequency;
+}
+
 static struct cpufreq_driver powernv_cpufreq_driver = {
.name   = "powernv-cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -904,6 +921,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.exit   = powernv_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = powernv_cpufreq_target_index,
+   .fast_switch= powernv_fast_switch,
.get= powernv_cpufreq_get,
.stop_cpu   = powernv_cpufreq_stop_cpu,
.attr   = powernv_cpu_freq_attr,
-- 
2.5.5

[PATCH v2 2/2] cpufreq: powernv: Use PMCR to verify global and local pstate

[Akshay Adiga]

As fast_switch() may get called with interrupt disable mode, we cannot
hold a mutex to update the global_pstate_info. So currently, fast_switch()
does not update the global_pstate_info and it will end up with stale data
whenever pstate is updated through fast_switch().

As the gpstate_timer can fire after fast_switch() has updated the pstates,
the timer handler cannot rely on the cached values of local and global
pstate and needs to read it from the PMCR.

Only gpstate_timer_handler() is affected by the stale cached pstate data
beacause either fast_switch() or target_index() routines will be called
for a given govenor, but gpstate_timer can fire after the governor has
changed to schedutil.


Signed-off-by: Akshay Adiga 
---

Changes from v1 :
- Corrected Commit message
- Type cast pstate values read from PMCR to type s8
- Added Macros to get local and global pstates from PMCR


 drivers/cpufreq/powernv-cpufreq.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index 4a4380d..bf4bc585 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -42,6 +42,8 @@
 #define PMSR_PSAFE_ENABLE  (1UL << 30)
 #define PMSR_SPR_EM_DISABLE(1UL << 31)
 #define PMSR_MAX(x)((x >> 32) & 0xFF)
+#define PMCR_LPSTATE(x)(((x) >> 48) & 0xFF)
+#define PMCR_GPSTATE(x)(((x) >> 56) & 0xFF)
 
 #define MAX_RAMP_DOWN_TIME 5120
 /*
@@ -592,7 +594,8 @@ void gpstate_timer_handler(unsigned long data)
 {
struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
struct global_pstate_info *gpstates = policy->driver_data;
-   int gpstate_idx;
+   int gpstate_idx, lpstate_idx;
+   unsigned long val;
unsigned int time_diff = jiffies_to_msecs(jiffies)
- gpstates->last_sampled_time;
struct powernv_smp_call_data freq_data;
@@ -600,21 +603,36 @@ void gpstate_timer_handler(unsigned long data)
if (!spin_trylock(>gpstate_lock))
return;
 
+   /*
+* If PMCR was last updated was using fast_swtich then
+* We may have wrong in gpstate->last_lpstate_idx
+* value. Hence, read from PMCR to get correct data.
+*/
+   val = get_pmspr(SPRN_PMCR);
+   freq_data.gpstate_id = (s8)PMCR_GPSTATE(val);
+   freq_data.pstate_id = (s8)PMCR_LPSTATE(val);
+   if (freq_data.gpstate_id  == freq_data.pstate_id) {
+   reset_gpstates(policy);
+   spin_unlock(>gpstate_lock);
+   return;
+   }
+
gpstates->last_sampled_time += time_diff;
gpstates->elapsed_time += time_diff;
-   freq_data.pstate_id = idx_to_pstate(gpstates->last_lpstate_idx);
 
-   if ((gpstates->last_gpstate_idx == gpstates->last_lpstate_idx) ||
-   (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME)) {
+   if (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME) {
gpstate_idx = pstate_to_idx(freq_data.pstate_id);
reset_gpstates(policy);
gpstates->highest_lpstate_idx = gpstate_idx;
} else {
+   lpstate_idx = pstate_to_idx(freq_data.pstate_id);
gpstate_idx = calc_global_pstate(gpstates->elapsed_time,
 gpstates->highest_lpstate_idx,
-gpstates->last_lpstate_idx);
+lpstate_idx);
}
-
+   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
+   gpstates->last_gpstate_idx = gpstate_idx;
+   gpstates->last_lpstate_idx = lpstate_idx;
/*
 * If local pstate is equal to global pstate, rampdown is over
 * So timer is not required to be queued.
@@ -622,10 +640,6 @@ void gpstate_timer_handler(unsigned long data)
if (gpstate_idx != gpstates->last_lpstate_idx)
queue_gpstate_timer(gpstates);
 
-   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
-   gpstates->last_gpstate_idx = pstate_to_idx(freq_data.gpstate_id);
-   gpstates->last_lpstate_idx = pstate_to_idx(freq_data.pstate_id);
-
spin_unlock(>gpstate_lock);
 
/* Timer may get migrated to a different cpu on cpu hot unplug */
-- 
2.5.5

[PATCH v2 1/2] cpufreq: powernv: Adding fast_switch for schedutil

[Akshay Adiga]

Adding fast_switch which does light weight operation to set the desired
pstate. Both global and local pstates are set to the same desired pstate.

Signed-off-by: Akshay Adiga 
---
Changes from v1 :
- Removed unnecessary check for index out of bound.

 drivers/cpufreq/powernv-cpufreq.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index d3ffde8..4a4380d 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -752,9 +752,12 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
spin_lock_init(>gpstate_lock);
ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
 
-   if (ret < 0)
+   if (ret < 0) {
kfree(policy->driver_data);
+   return ret;
+   }
 
+   policy->fast_switch_possible = true;
return ret;
 }
 
@@ -897,6 +900,20 @@ static void powernv_cpufreq_stop_cpu(struct cpufreq_policy 
*policy)
del_timer_sync(>timer);
 }
 
+static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   int index;
+   struct powernv_smp_call_data freq_data;
+
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+   freq_data.pstate_id = powernv_freqs[index].driver_data;
+   freq_data.gpstate_id = powernv_freqs[index].driver_data;
+   set_pstate(_data);
+
+   return powernv_freqs[index].frequency;
+}
+
 static struct cpufreq_driver powernv_cpufreq_driver = {
.name   = "powernv-cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -904,6 +921,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.exit   = powernv_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = powernv_cpufreq_target_index,
+   .fast_switch= powernv_fast_switch,
.get= powernv_cpufreq_get,
.stop_cpu   = powernv_cpufreq_stop_cpu,
.attr   = powernv_cpu_freq_attr,
-- 
2.5.5

[PATCH v2 2/2] cpufreq: powernv: Use PMCR to verify global and local pstate

[Akshay Adiga]

As fast_switch() may get called with interrupt disable mode, we cannot
hold a mutex to update the global_pstate_info. So currently, fast_switch()
does not update the global_pstate_info and it will end up with stale data
whenever pstate is updated through fast_switch().

As the gpstate_timer can fire after fast_switch() has updated the pstates,
the timer handler cannot rely on the cached values of local and global
pstate and needs to read it from the PMCR.

Only gpstate_timer_handler() is affected by the stale cached pstate data
beacause either fast_switch() or target_index() routines will be called
for a given govenor, but gpstate_timer can fire after the governor has
changed to schedutil.


Signed-off-by: Akshay Adiga 
---

Changes from v1 :
- Corrected Commit message
- Type cast pstate values read from PMCR to type s8
- Added Macros to get local and global pstates from PMCR


 drivers/cpufreq/powernv-cpufreq.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index 4a4380d..bf4bc585 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -42,6 +42,8 @@
 #define PMSR_PSAFE_ENABLE  (1UL << 30)
 #define PMSR_SPR_EM_DISABLE(1UL << 31)
 #define PMSR_MAX(x)((x >> 32) & 0xFF)
+#define PMCR_LPSTATE(x)(((x) >> 48) & 0xFF)
+#define PMCR_GPSTATE(x)(((x) >> 56) & 0xFF)
 
 #define MAX_RAMP_DOWN_TIME 5120
 /*
@@ -592,7 +594,8 @@ void gpstate_timer_handler(unsigned long data)
 {
struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
struct global_pstate_info *gpstates = policy->driver_data;
-   int gpstate_idx;
+   int gpstate_idx, lpstate_idx;
+   unsigned long val;
unsigned int time_diff = jiffies_to_msecs(jiffies)
- gpstates->last_sampled_time;
struct powernv_smp_call_data freq_data;
@@ -600,21 +603,36 @@ void gpstate_timer_handler(unsigned long data)
if (!spin_trylock(>gpstate_lock))
return;
 
+   /*
+* If PMCR was last updated was using fast_swtich then
+* We may have wrong in gpstate->last_lpstate_idx
+* value. Hence, read from PMCR to get correct data.
+*/
+   val = get_pmspr(SPRN_PMCR);
+   freq_data.gpstate_id = (s8)PMCR_GPSTATE(val);
+   freq_data.pstate_id = (s8)PMCR_LPSTATE(val);
+   if (freq_data.gpstate_id  == freq_data.pstate_id) {
+   reset_gpstates(policy);
+   spin_unlock(>gpstate_lock);
+   return;
+   }
+
gpstates->last_sampled_time += time_diff;
gpstates->elapsed_time += time_diff;
-   freq_data.pstate_id = idx_to_pstate(gpstates->last_lpstate_idx);
 
-   if ((gpstates->last_gpstate_idx == gpstates->last_lpstate_idx) ||
-   (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME)) {
+   if (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME) {
gpstate_idx = pstate_to_idx(freq_data.pstate_id);
reset_gpstates(policy);
gpstates->highest_lpstate_idx = gpstate_idx;
} else {
+   lpstate_idx = pstate_to_idx(freq_data.pstate_id);
gpstate_idx = calc_global_pstate(gpstates->elapsed_time,
 gpstates->highest_lpstate_idx,
-gpstates->last_lpstate_idx);
+lpstate_idx);
}
-
+   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
+   gpstates->last_gpstate_idx = gpstate_idx;
+   gpstates->last_lpstate_idx = lpstate_idx;
/*
 * If local pstate is equal to global pstate, rampdown is over
 * So timer is not required to be queued.
@@ -622,10 +640,6 @@ void gpstate_timer_handler(unsigned long data)
if (gpstate_idx != gpstates->last_lpstate_idx)
queue_gpstate_timer(gpstates);
 
-   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
-   gpstates->last_gpstate_idx = pstate_to_idx(freq_data.gpstate_id);
-   gpstates->last_lpstate_idx = pstate_to_idx(freq_data.pstate_id);
-
spin_unlock(>gpstate_lock);
 
/* Timer may get migrated to a different cpu on cpu hot unplug */
-- 
2.5.5

Re: [RFC PATCH 0/3] x86/RAS: Dump error record to dmesg if no consumers

[Ingo Molnar]

* Borislav Petkov  wrote:

> From: Borislav Petkov 
> 
> Right,
> 
> so this is not a good thing: systems may not have any error record
> consumers registered and in such cases, any logged MCEs disappear into
> the void. And this shouldn't happen.
> 
> So let's dump them to dmesg as a last resort.
> 
> Borislav Petkov (3):
>   notifiers: Document notifier priority
>   x86/RAS: Add TSC to the injected MCE
>   x86/MCE: Dump MCE to dmesg if no consumers
> 
>  arch/x86/kernel/cpu/mcheck/mce.c | 52 
> +++-
>  arch/x86/ras/mce_amd_inj.c   |  2 ++
>  include/linux/notifier.h |  1 +
>  3 files changed, 49 insertions(+), 6 deletions(-)

Sounds good to me!

Thanks,

Ingo

Re: [RFC PATCH 0/3] x86/RAS: Dump error record to dmesg if no consumers

[Ingo Molnar]

* Borislav Petkov  wrote:

> From: Borislav Petkov 
> 
> Right,
> 
> so this is not a good thing: systems may not have any error record
> consumers registered and in such cases, any logged MCEs disappear into
> the void. And this shouldn't happen.
> 
> So let's dump them to dmesg as a last resort.
> 
> Borislav Petkov (3):
>   notifiers: Document notifier priority
>   x86/RAS: Add TSC to the injected MCE
>   x86/MCE: Dump MCE to dmesg if no consumers
> 
>  arch/x86/kernel/cpu/mcheck/mce.c | 52 
> +++-
>  arch/x86/ras/mce_amd_inj.c   |  2 ++
>  include/linux/notifier.h |  1 +
>  3 files changed, 49 insertions(+), 6 deletions(-)

Sounds good to me!

Thanks,

Ingo

Re: [PATCH 2/2] cpufreq: powernv: Use PMSR to verify global and local pstate

[Akshay Adiga]

Thanks Viresh for taking a look at it.

I will make the mentioned changes in the next version of the patch and
will add Shilpa and Gautham to the mail chain.

Regards

Akshay Adiga


On 11/04/2016 12:11 PM, Viresh Kumar wrote:

On 04-11-16, 10:57, Akshay Adiga wrote:

As fast_switch may get called in interrupt disable mode, it does not

s/in interrupt disable mode/with interrupts disabled
s/it does/it may


update the global_pstate_info data structure. Hence the global_pstate_info
has stale data whenever pstate is updated through fast_swtich().

s/has/may have
s/swtich/switch


So the gpstate_timer can fire after a fast_switch() call has update

s/So the/The
s/a fast_swtich() call has update/the fast_switch() call has updated


the pstates to a different value. Hence the timer handler cannot rely
on the cached values of local and global pstate and needs to read it
from the PMSR.

Signed-off-by: Akshay Adiga 

---
  drivers/cpufreq/powernv-cpufreq.c | 32 ++--
  1 file changed, 22 insertions(+), 10 deletions(-)

I am not the best guy to judge the code changes here. Can you please include
Shilpa and Gautham to the mail chain and get there feedback.

Re: [PATCH 2/2] cpufreq: powernv: Use PMSR to verify global and local pstate

[Akshay Adiga]

Thanks Viresh for taking a look at it.

I will make the mentioned changes in the next version of the patch and
will add Shilpa and Gautham to the mail chain.

Regards

Akshay Adiga


On 11/04/2016 12:11 PM, Viresh Kumar wrote:

On 04-11-16, 10:57, Akshay Adiga wrote:

As fast_switch may get called in interrupt disable mode, it does not

s/in interrupt disable mode/with interrupts disabled
s/it does/it may


update the global_pstate_info data structure. Hence the global_pstate_info
has stale data whenever pstate is updated through fast_swtich().

s/has/may have
s/swtich/switch


So the gpstate_timer can fire after a fast_switch() call has update

s/So the/The
s/a fast_swtich() call has update/the fast_switch() call has updated


the pstates to a different value. Hence the timer handler cannot rely
on the cached values of local and global pstate and needs to read it
from the PMSR.

Signed-off-by: Akshay Adiga 

---
  drivers/cpufreq/powernv-cpufreq.c | 32 ++--
  1 file changed, 22 insertions(+), 10 deletions(-)

I am not the best guy to judge the code changes here. Can you please include
Shilpa and Gautham to the mail chain and get there feedback.

Re: [PATCH v3 1/2] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems

[Ingo Molnar]

* Borislav Petkov  wrote:

> Lemme clean up the commit message a bit more and add tags:
> 
> ---
> From: Yazen Ghannam 
> Date: Tue, 1 Nov 2016 11:51:02 -0500
> Subject: [PATCH] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems
> 
> cpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an
> underflow bug when extracting the socket_id value. It starts from 0
> so subtracting 1 from it will result in an invalid value. This breaks
> scheduling topology later on since the cpu_llc_id will be incorrect.
> 
> The APIC ID is preset in APICx020 for bits 3 and above: they contain the
> core complex, node and socket IDs.
> 
> The LLC is at the core complex level so we can find a unique cpu_llc_id
> by right shifting the APICID by 3 because then the least significant bit
> will be the Core Complex ID.

Same question as for the previous patch: what are the effects of the bug:

 - Outright bad scheduling?
 - Suboptimal scheduling?
 - Crash?
 - Something else?

Such information needs to be in commit messages, _especially_ when a Cc: stable 
tag is added as well.

Thanks,

Ingo

Re: [PATCH v3 1/2] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems

[Ingo Molnar]

* Borislav Petkov  wrote:

> Lemme clean up the commit message a bit more and add tags:
> 
> ---
> From: Yazen Ghannam 
> Date: Tue, 1 Nov 2016 11:51:02 -0500
> Subject: [PATCH] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems
> 
> cpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an
> underflow bug when extracting the socket_id value. It starts from 0
> so subtracting 1 from it will result in an invalid value. This breaks
> scheduling topology later on since the cpu_llc_id will be incorrect.
> 
> The APIC ID is preset in APICx020 for bits 3 and above: they contain the
> core complex, node and socket IDs.
> 
> The LLC is at the core complex level so we can find a unique cpu_llc_id
> by right shifting the APICID by 3 because then the least significant bit
> will be the Core Complex ID.

Same question as for the previous patch: what are the effects of the bug:

 - Outright bad scheduling?
 - Suboptimal scheduling?
 - Crash?
 - Something else?

Such information needs to be in commit messages, _especially_ when a Cc: stable 
tag is added as well.

Thanks,

Ingo

[PATCH v3 0/2] set specific ddr frequency when stop ddr dvfs

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop working. So we
implement get suspend frequency function in devfreq framework, and call
it in rk3399 dmc driver. 

Lin Huang (2):
  PM/devfreq: add suspend frequency support
  PM/devfreq: rk3399: get devfreq suspend frequency

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 drivers/devfreq/rk3399_dmc.c  |  2 +-
 include/linux/devfreq.h   |  8 
 4 files changed, 34 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH v3 0/2] set specific ddr frequency when stop ddr dvfs

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop working. So we
implement get suspend frequency function in devfreq framework, and call
it in rk3399 dmc driver. 

Lin Huang (2):
  PM/devfreq: add suspend frequency support
  PM/devfreq: rk3399: get devfreq suspend frequency

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 drivers/devfreq/rk3399_dmc.c  |  2 +-
 include/linux/devfreq.h   |  8 
 4 files changed, 34 insertions(+), 3 deletions(-)

-- 
1.9.1

Re: [PATCH v3 2/2] x86/AMD: Group cpu_llc_id assignment by topology feature and family

[Ingo Molnar]

* Borislav Petkov  wrote:

> Ditto, clean it up and add tags:
> 
> ---
> From: Yazen Ghannam 
> Date: Tue, 1 Nov 2016 11:51:03 -0500
> Subject: [PATCH] x86/AMD: Group cpu_llc_id assignment
> 
> Currently, we assume that a system has multiple last level caches only
> if there are multiple nodes, and that the cpu_llc_id is equal to the
> node_id. This no longer applies since Fam17h can have multiple last
> level caches within a node.

Wondering what the practical effect of this is - is any current hardware 
affected, 
and if yes, what are the effects of this patch?

Thanks,

Ingo

Re: [PATCH v3 2/2] x86/AMD: Group cpu_llc_id assignment by topology feature and family

[Ingo Molnar]

* Borislav Petkov  wrote:

> Ditto, clean it up and add tags:
> 
> ---
> From: Yazen Ghannam 
> Date: Tue, 1 Nov 2016 11:51:03 -0500
> Subject: [PATCH] x86/AMD: Group cpu_llc_id assignment
> 
> Currently, we assume that a system has multiple last level caches only
> if there are multiple nodes, and that the cpu_llc_id is equal to the
> node_id. This no longer applies since Fam17h can have multiple last
> level caches within a node.

Wondering what the practical effect of this is - is any current hardware 
affected, 
and if yes, what are the effects of this patch?

Thanks,

Ingo

[PATCH V2 linux-next] ext4: fix block_validity definition

[Fabian Frederick]

Fix ext4 documentation according to commit 45f1a9c3f63d
("ext4: enable block_validity by default")

Also fix some typos.

Reviewed-by: Darrick J. Wong 
Signed-off-by: Fabian Frederick 
---
V2: Replace beginning of the definition (suggested by Darrick). 

 Documentation/filesystems/ext4.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/filesystems/ext4.txt 
b/Documentation/filesystems/ext4.txt
index 6c0108e..1d92713 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -351,14 +351,13 @@ nouid32   Disables 32-bit UIDs and GIDs.  
This is for
interoperability  with  older kernels which only
store and expect 16-bit values.
 
-block_validity This options allows to enables/disables the in-kernel
+block_validity(*)  These options enable or disable the in-kernel
 noblock_validity   facility for tracking filesystem metadata blocks
within internal data structures. This allows multi-
block allocator and other routines to quickly locate
extents which might overlap with filesystem metadata
-   blocks. This option is intended for debugging
-   purposes and since it negatively affects the
-   performance, it is off by default.
+   blocks. Initially intended for debugging, it's now
+   enabled by default.
 
 dioread_lock   Controls whether or not ext4 should use the DIO read
 dioread_nolock locking. If the dioread_nolock option is specified
-- 
2.7.4

[PATCH V2 linux-next] ext4: fix block_validity definition

[Fabian Frederick]

Fix ext4 documentation according to commit 45f1a9c3f63d
("ext4: enable block_validity by default")

Also fix some typos.

Reviewed-by: Darrick J. Wong 
Signed-off-by: Fabian Frederick 
---
V2: Replace beginning of the definition (suggested by Darrick). 

 Documentation/filesystems/ext4.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/filesystems/ext4.txt 
b/Documentation/filesystems/ext4.txt
index 6c0108e..1d92713 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -351,14 +351,13 @@ nouid32   Disables 32-bit UIDs and GIDs.  
This is for
interoperability  with  older kernels which only
store and expect 16-bit values.
 
-block_validity This options allows to enables/disables the in-kernel
+block_validity(*)  These options enable or disable the in-kernel
 noblock_validity   facility for tracking filesystem metadata blocks
within internal data structures. This allows multi-
block allocator and other routines to quickly locate
extents which might overlap with filesystem metadata
-   blocks. This option is intended for debugging
-   purposes and since it negatively affects the
-   performance, it is off by default.
+   blocks. Initially intended for debugging, it's now
+   enabled by default.
 
 dioread_lock   Controls whether or not ext4 should use the DIO read
 dioread_nolock locking. If the dioread_nolock option is specified
-- 
2.7.4

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Joonsoo Kim]

On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
> 
> 
> On 2016/11/7 14:15, Joonsoo Kim wrote:
> > On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> >> Hello, I hava a question on cma zone.
> >>
> >> When we have cma zone, cma zone will be the highest zone of system.
> >>
> >> In android system, the most memory allocator is ION. Media system will
> >> alloc unmovable memory from it.
> >>
> >> On low memory scene, will the CMA zone always do balance?
> > 
> > Allocation request for low zone (normal zone) would not cause CMA zone
> > to be balanced since it isn't helpful.
> > 
> Yes. But the cma zone will run out soon. And it always need to do balance.
> 
> How about use migrate cma before movable and let cma type to fallback movable.
> 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html

ZONE_CMA approach will act like as your solution. Could you elaborate
more on the problem of zone approach?

Thanks.

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Joonsoo Kim]

On Mon, Nov 07, 2016 at 03:08:49PM +0800, Chen Feng wrote:
> 
> 
> On 2016/11/7 14:15, Joonsoo Kim wrote:
> > On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> >> Hello, I hava a question on cma zone.
> >>
> >> When we have cma zone, cma zone will be the highest zone of system.
> >>
> >> In android system, the most memory allocator is ION. Media system will
> >> alloc unmovable memory from it.
> >>
> >> On low memory scene, will the CMA zone always do balance?
> > 
> > Allocation request for low zone (normal zone) would not cause CMA zone
> > to be balanced since it isn't helpful.
> > 
> Yes. But the cma zone will run out soon. And it always need to do balance.
> 
> How about use migrate cma before movable and let cma type to fallback movable.
> 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html

ZONE_CMA approach will act like as your solution. Could you elaborate
more on the problem of zone approach?

Thanks.

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

On 2016/11/7 14:15, Joonsoo Kim wrote:
> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
>> Hello, I hava a question on cma zone.
>>
>> When we have cma zone, cma zone will be the highest zone of system.
>>
>> In android system, the most memory allocator is ION. Media system will
>> alloc unmovable memory from it.
>>
>> On low memory scene, will the CMA zone always do balance?
> 
> Allocation request for low zone (normal zone) would not cause CMA zone
> to be balanced since it isn't helpful.
> 
Yes. But the cma zone will run out soon. And it always need to do balance.

How about use migrate cma before movable and let cma type to fallback movable.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html

>> Should we transmit the highest available zone to kswapd？
> 
> It is already done when necessary.
> 
> Thanks.
> 
> 
> .
> 

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

On 2016/11/7 14:15, Joonsoo Kim wrote:
> On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
>> Hello, I hava a question on cma zone.
>>
>> When we have cma zone, cma zone will be the highest zone of system.
>>
>> In android system, the most memory allocator is ION. Media system will
>> alloc unmovable memory from it.
>>
>> On low memory scene, will the CMA zone always do balance?
> 
> Allocation request for low zone (normal zone) would not cause CMA zone
> to be balanced since it isn't helpful.
> 
Yes. But the cma zone will run out soon. And it always need to do balance.

How about use migrate cma before movable and let cma type to fallback movable.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1263745.html

>> Should we transmit the highest available zone to kswapd？
> 
> It is already done when necessary.
> 
> Thanks.
> 
> 
> .
> 

Photos of Kernel Summit & Plumber's in Santa Fe

[Len Brown]

https://goo.gl/photos/4YUMndSYj6Ztcw3dA

Enjoy!

cheers,
-Len

Photos of Kernel Summit & Plumber's in Santa Fe

[Len Brown]

https://goo.gl/photos/4YUMndSYj6Ztcw3dA

Enjoy!

cheers,
-Len

Re: [PATCH 2/2] s390: squash facilities_src.h into gen_facilities.c

[Heiko Carstens]

On Sun, Nov 06, 2016 at 12:45:28PM +0900, Masahiro Yamada wrote:
> We generally expect headers in arch/$(ARCH)/include/asm directory
> are included from kernel sources, but facilities_src.h is not;
> it is included from the arch/s390/tools/gen_facilities.c tool.
> 
> There is no reason to expose this header to the public include path.
> Furthermore, facilities_src.h makes sure to be included only from
> gen_facilities.c by the following:
> 
>   #ifndef S390_GEN_FACILITIES_C
>   #error "This file can only be included by gen_facilities.c"
>   #endif
> 
> This check can be removed by merging the two files.
> 
> Signed-off-by: Masahiro Yamada 
> ---

Both patches:
Acked-by: Heiko Carstens 

Martin, can you please pick them up?

Re: [PATCH 2/2] s390: squash facilities_src.h into gen_facilities.c

[Heiko Carstens]

On Sun, Nov 06, 2016 at 12:45:28PM +0900, Masahiro Yamada wrote:
> We generally expect headers in arch/$(ARCH)/include/asm directory
> are included from kernel sources, but facilities_src.h is not;
> it is included from the arch/s390/tools/gen_facilities.c tool.
> 
> There is no reason to expose this header to the public include path.
> Furthermore, facilities_src.h makes sure to be included only from
> gen_facilities.c by the following:
> 
>   #ifndef S390_GEN_FACILITIES_C
>   #error "This file can only be included by gen_facilities.c"
>   #endif
> 
> This check can be removed by merging the two files.
> 
> Signed-off-by: Masahiro Yamada 
> ---

Both patches:
Acked-by: Heiko Carstens 

Martin, can you please pick them up?

[PATCH v4 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Rick Chang]

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
 arch/arm/boot/dts/mt2701.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..a929df2 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
 
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
1.9.1

[PATCH v4 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Rick Chang]

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
 arch/arm/boot/dts/mt2701.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..a929df2 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
 
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
1.9.1

[PATCH v4 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

[Rick Chang]

Add v4l2 driver for Mediatek JPEG Decoder

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig   |   15 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/Makefile |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1271 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
 10 files changed, 2182 insertions(+)
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_JPEG
+   tristate "Mediatek JPEG Codec driver"
+   depends on MTK_IOMMU_V1 || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..808f175
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1271 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ * Rick Chang 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+   {
+   .name   = "JPEG JFIF",
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   },
+   {
+   .name   = "YUV 4:2:0 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV420M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 3,
+   .h_align= 5,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   },
+   {
+   .name   = "YUV 4:2:2 non-contiguous 3-planar, 

[PATCH v4 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

[Rick Chang]

Add v4l2 driver for Mediatek JPEG Decoder

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig   |   15 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/Makefile |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1271 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
 10 files changed, 2182 insertions(+)
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_JPEG
+   tristate "Mediatek JPEG Codec driver"
+   depends on MTK_IOMMU_V1 || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..808f175
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1271 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ * Rick Chang 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+   {
+   .name   = "JPEG JFIF",
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   },
+   {
+   .name   = "YUV 4:2:0 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV420M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 3,
+   .h_align= 5,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   },
+   {
+   .name   = "YUV 4:2:2 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV422M,
+   .h_sample   = {4, 2, 2},
+   

[PATCH v4 0/3] Add Mediatek JPEG Decoder

[Rick Chang]

This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPEG image and Motion JPEG bitstream.

changes since v3:
- Revise DT binding documentation
- Revise compatible string

changes since v2:
- Revise DT binding documentation 

changes since v1:
- Rebase for v4.9-rc1.
- Update Compliance test version and result
- Remove redundant path in Makefile
- Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
- Fix warnings from patch check and smatch check

* Dependency
The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/

* Compliance test
v4l2-compliance SHA   : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a

Driver Info:
Driver name   : mtk-jpeg decode
Card type : mtk-jpeg decoder
Bus info  : platform:15004000.jpegdec
Driver version: 4.9.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0

Rick Chang (3):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  arm: dts: mt2701: Add node for Mediatek JPEG Decoder

 .../bindings/media/mediatek-jpeg-codec.txt |   35 +
 arch/arm/boot/dts/mt2701.dtsi  |   14 +
 drivers/media/platform/Kconfig |   15 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-jpeg/Makefile   |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c| 1271 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h|  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c  |  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h  |   91 ++
 

[PATCH v4 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 .../bindings/media/mediatek-jpeg-codec.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
new file mode 100644
index 000..c7dbcc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
@@ -0,0 +1,35 @@
+* Mediatek JPEG Decoder
+
+Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs
+
+Required properties:
+- compatible : "mediatek,jpgdec"
+- reg : physical base address of the jpeg decoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgdec-smi" and "jpgdec".
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
-- 
1.9.1

[PATCH v4 0/3] Add Mediatek JPEG Decoder

[Rick Chang]

This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPEG image and Motion JPEG bitstream.

changes since v3:
- Revise DT binding documentation
- Revise compatible string

changes since v2:
- Revise DT binding documentation 

changes since v1:
- Rebase for v4.9-rc1.
- Update Compliance test version and result
- Remove redundant path in Makefile
- Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
- Fix warnings from patch check and smatch check

* Dependency
The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/

* Compliance test
v4l2-compliance SHA   : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a

Driver Info:
Driver name   : mtk-jpeg decode
Card type : mtk-jpeg decoder
Bus info  : platform:15004000.jpegdec
Driver version: 4.9.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0

Rick Chang (3):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  arm: dts: mt2701: Add node for Mediatek JPEG Decoder

 .../bindings/media/mediatek-jpeg-codec.txt |   35 +
 arch/arm/boot/dts/mt2701.dtsi  |   14 +
 drivers/media/platform/Kconfig |   15 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-jpeg/Makefile   |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c| 1271 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h|  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c  |  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h  |   91 ++
 

[PATCH v4 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 .../bindings/media/mediatek-jpeg-codec.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
new file mode 100644
index 000..c7dbcc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
@@ -0,0 +1,35 @@
+* Mediatek JPEG Decoder
+
+Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs
+
+Required properties:
+- compatible : "mediatek,jpgdec"
+- reg : physical base address of the jpeg decoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgdec-smi" and "jpgdec".
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
-- 
1.9.1

Re: [PATCH v11 00/22] Add Mediated device support

[Alexey Kardashevskiy]

On 07/11/16 17:36, Kirti Wankhede wrote:
> 
> 
> On 11/7/2016 11:45 AM, Alexey Kardashevskiy wrote:
>> On 07/11/16 14:59, Kirti Wankhede wrote:
>>>
>>>
>>> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
 On 05/11/16 08:10, Kirti Wankhede wrote:
> 
> ...
> 
>
>   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
>   Resolved against conflicting change:

 Patch 11/22 does not apply if the patchset is applied on top of 
 14970f204b19.


>>>
>>> Pull commit 05692d7005a3 (below) commit.
>>
>> Nah, it was my fault, thunderbird's plugin saved mails in wrong order,
>> false alarm, sorry.
>>
>> Speaking of order, 11/22 is better be squashed into 02/22 (as it does not
>> seem to make sense alone; it also does not depend on something between
>> 02/22 and 11/22); and both 01/22 and 02/22 better be moved where "docs"
>> patches start as they do not makes sense earlier anyway, or do they?
>>
>>
> 
> There are dependencies in the patch series:
> Patch 10/22 depends on patch 01/22 and patch 03/22 to 09/22 patch.
> 
> Patch 02/22 depends on patch 01/22.
> 
> Patch 11/22 doesn't make sense without patch 10/22.
> 
> Patch 12/22 depends on patch 11/22.
> 
> Patch 13/22 to 18/22 are independent, pulling common code in functions.
> But patch 21/22 uses these APIs in sample driver, so has to be before that.
> 
> Patch 19/22 adds basic documentation.
> Patch 21/22 depends on 19/22 patch because that adds sample driver and
> its explanation to documentation.


Ouch, I get it now, sorry. I was compiling on ppc64 and everything related
to iommu type1 (i.e. x86) just got skipped.



-- 
Alexey

Re: [PATCH v11 00/22] Add Mediated device support

[Alexey Kardashevskiy]

On 07/11/16 17:36, Kirti Wankhede wrote:
> 
> 
> On 11/7/2016 11:45 AM, Alexey Kardashevskiy wrote:
>> On 07/11/16 14:59, Kirti Wankhede wrote:
>>>
>>>
>>> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
 On 05/11/16 08:10, Kirti Wankhede wrote:
> 
> ...
> 
>
>   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
>   Resolved against conflicting change:

 Patch 11/22 does not apply if the patchset is applied on top of 
 14970f204b19.


>>>
>>> Pull commit 05692d7005a3 (below) commit.
>>
>> Nah, it was my fault, thunderbird's plugin saved mails in wrong order,
>> false alarm, sorry.
>>
>> Speaking of order, 11/22 is better be squashed into 02/22 (as it does not
>> seem to make sense alone; it also does not depend on something between
>> 02/22 and 11/22); and both 01/22 and 02/22 better be moved where "docs"
>> patches start as they do not makes sense earlier anyway, or do they?
>>
>>
> 
> There are dependencies in the patch series:
> Patch 10/22 depends on patch 01/22 and patch 03/22 to 09/22 patch.
> 
> Patch 02/22 depends on patch 01/22.
> 
> Patch 11/22 doesn't make sense without patch 10/22.
> 
> Patch 12/22 depends on patch 11/22.
> 
> Patch 13/22 to 18/22 are independent, pulling common code in functions.
> But patch 21/22 uses these APIs in sample driver, so has to be before that.
> 
> Patch 19/22 adds basic documentation.
> Patch 21/22 depends on 19/22 patch because that adds sample driver and
> its explanation to documentation.


Ouch, I get it now, sorry. I was compiling on ppc64 and everything related
to iommu type1 (i.e. x86) just got skipped.



-- 
Alexey

Re: [PATCH] staging: lustre: o2iblnd: replace space indentation with tabs

[Greg KH]

On Mon, Nov 07, 2016 at 03:55:36AM +, James Simmons wrote:
> 
> > On Mon, 2016-11-07 at 02:02 +, James Simmons wrote:
> > > > This patch fixes all CODE_INDENT checkpatch errors in o2iblnd.
> > > Reviewed-by: James Simmons 
> > []
> > > > diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
> > > > b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> > []
> > > > @@ -1637,7 +1637,7 @@ int kiblnd_fmr_pool_map(struct kib_fmr_poolset 
> > > > *fps, struct kib_tx *tx,
> > > >  {
> > > > __u64 *pages = tx->tx_pages;
> > > > bool is_rx = (rd != tx->tx_rd);
> > > > -bool tx_pages_mapped = 0;
> > > > +   bool tx_pages_mapped = 0;
> > 
> > It's generally better to use bool assignments to true/false not 1/0.
> 
> Nicholas can you resubmit with tx_pages_mapped = false. Looking at the 
> lustre code its the only place like this. Thanks for pointing this out.

No, make it a separate patch, don't change code when you are just
changing indentation in the same patch.

Re: [PATCH] staging: lustre: o2iblnd: replace space indentation with tabs

[Greg KH]

On Mon, Nov 07, 2016 at 03:55:36AM +, James Simmons wrote:
> 
> > On Mon, 2016-11-07 at 02:02 +, James Simmons wrote:
> > > > This patch fixes all CODE_INDENT checkpatch errors in o2iblnd.
> > > Reviewed-by: James Simmons 
> > []
> > > > diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
> > > > b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> > []
> > > > @@ -1637,7 +1637,7 @@ int kiblnd_fmr_pool_map(struct kib_fmr_poolset 
> > > > *fps, struct kib_tx *tx,
> > > >  {
> > > > __u64 *pages = tx->tx_pages;
> > > > bool is_rx = (rd != tx->tx_rd);
> > > > -bool tx_pages_mapped = 0;
> > > > +   bool tx_pages_mapped = 0;
> > 
> > It's generally better to use bool assignments to true/false not 1/0.
> 
> Nicholas can you resubmit with tx_pages_mapped = false. Looking at the 
> lustre code its the only place like this. Thanks for pointing this out.

No, make it a separate patch, don't change code when you are just
changing indentation in the same patch.

RE: [PATCH v11 01/22] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Saturday, November 05, 2016 5:11 AM
> 
[...]
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: I73a5084574270b14541c529461ea2f03c292d510

Jike has given his reviewed-by for some patches in v10. Please include
his reviewed-by in new version, which represent acknowledgements
from our side and also be informative to other reviewers.

Thanks
Kevin

RE: [PATCH v11 01/22] vfio: Mediated device Core driver

[Tian, Kevin]

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com]
> Sent: Saturday, November 05, 2016 5:11 AM
> 
[...]
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: I73a5084574270b14541c529461ea2f03c292d510

Jike has given his reviewed-by for some patches in v10. Please include
his reviewed-by in new version, which represent acknowledgements
from our side and also be informative to other reviewers.

Thanks
Kevin

[PATCH v3 2/2] PM/devfreq: rk3399: get devfreq suspend frequency

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop
working. For example: if we enable two monitor, then we will
stop ddr dvfs, but we hope ddr can run in highest frequency
obviously.

Signed-off-by: Lin Huang 
---
Changes in v2:
- None
Changes in v3:
- None

 drivers/devfreq/rk3399_dmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 5a2da95..39f8e27 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -329,7 +329,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
devm_devfreq_register_opp_notifier(dev, data->devfreq);
-
+   devfreq_opp_get_suspend_opp(dev, data->devfreq);
data->dev = dev;
platform_set_drvdata(pdev, data);
pd_register_notify_to_dmc(data->devfreq);
-- 
1.9.1

[PATCH v3 2/2] PM/devfreq: rk3399: get devfreq suspend frequency

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop
working. For example: if we enable two monitor, then we will
stop ddr dvfs, but we hope ddr can run in highest frequency
obviously.

Signed-off-by: Lin Huang 
---
Changes in v2:
- None
Changes in v3:
- None

 drivers/devfreq/rk3399_dmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 5a2da95..39f8e27 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -329,7 +329,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
devm_devfreq_register_opp_notifier(dev, data->devfreq);
-
+   devfreq_opp_get_suspend_opp(dev, data->devfreq);
data->dev = dev;
platform_set_drvdata(pdev, data);
pd_register_notify_to_dmc(data->devfreq);
-- 
1.9.1

Re: [PATCH v11 00/22] Add Mediated device support

[Kirti Wankhede]

On 11/7/2016 11:45 AM, Alexey Kardashevskiy wrote:
> On 07/11/16 14:59, Kirti Wankhede wrote:
>>
>>
>> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
>>> On 05/11/16 08:10, Kirti Wankhede wrote:

...


   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
   Resolved against conflicting change:
>>>
>>> Patch 11/22 does not apply if the patchset is applied on top of 
>>> 14970f204b19.
>>>
>>>
>>
>> Pull commit 05692d7005a3 (below) commit.
> 
> Nah, it was my fault, thunderbird's plugin saved mails in wrong order,
> false alarm, sorry.
> 
> Speaking of order, 11/22 is better be squashed into 02/22 (as it does not
> seem to make sense alone; it also does not depend on something between
> 02/22 and 11/22); and both 01/22 and 02/22 better be moved where "docs"
> patches start as they do not makes sense earlier anyway, or do they?
> 
> 

There are dependencies in the patch series:
Patch 10/22 depends on patch 01/22 and patch 03/22 to 09/22 patch.

Patch 02/22 depends on patch 01/22.

Patch 11/22 doesn't make sense without patch 10/22.

Patch 12/22 depends on patch 11/22.

Patch 13/22 to 18/22 are independent, pulling common code in functions.
But patch 21/22 uses these APIs in sample driver, so has to be before that.

Patch 19/22 adds basic documentation.
Patch 21/22 depends on 19/22 patch because that adds sample driver and
its explanation to documentation.

Thanks,
Kirti

Re: [PATCH v11 00/22] Add Mediated device support

[Kirti Wankhede]

On 11/7/2016 11:45 AM, Alexey Kardashevskiy wrote:
> On 07/11/16 14:59, Kirti Wankhede wrote:
>>
>>
>> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
>>> On 05/11/16 08:10, Kirti Wankhede wrote:

...


   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
   Resolved against conflicting change:
>>>
>>> Patch 11/22 does not apply if the patchset is applied on top of 
>>> 14970f204b19.
>>>
>>>
>>
>> Pull commit 05692d7005a3 (below) commit.
> 
> Nah, it was my fault, thunderbird's plugin saved mails in wrong order,
> false alarm, sorry.
> 
> Speaking of order, 11/22 is better be squashed into 02/22 (as it does not
> seem to make sense alone; it also does not depend on something between
> 02/22 and 11/22); and both 01/22 and 02/22 better be moved where "docs"
> patches start as they do not makes sense earlier anyway, or do they?
> 
> 

There are dependencies in the patch series:
Patch 10/22 depends on patch 01/22 and patch 03/22 to 09/22 patch.

Patch 02/22 depends on patch 01/22.

Patch 11/22 doesn't make sense without patch 10/22.

Patch 12/22 depends on patch 11/22.

Patch 13/22 to 18/22 are independent, pulling common code in functions.
But patch 21/22 uses these APIs in sample driver, so has to be before that.

Patch 19/22 adds basic documentation.
Patch 21/22 depends on 19/22 patch because that adds sample driver and
its explanation to documentation.

Thanks,
Kirti

Hello Dear

[CatherineWormer]

I am Sgt Catherine Wormer a self sufficient, hard working woman that enjoys 
hanging out with friends and family. I love learning new things and going new 
places. I'm down to earth, loving, I'm direct, loyal, funny, and honest. Please 
respond to my mail at my private box ( catherineworme...@gmail.com ) so I can 
send you my photo and details about me, 


Sgt Catherine Wormer

Hello Dear

[CatherineWormer]

I am Sgt Catherine Wormer a self sufficient, hard working woman that enjoys 
hanging out with friends and family. I love learning new things and going new 
places. I'm down to earth, loving, I'm direct, loyal, funny, and honest. Please 
respond to my mail at my private box ( catherineworme...@gmail.com ) so I can 
send you my photo and details about me, 


Sgt Catherine Wormer

[RESEND PATCH v3 2/2] PM/devfreq: rk3399: get devfreq suspend frequency

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop
working. For example: if we enable two monitor, then we will
stop ddr dvfs, but we hope ddr can run in highest frequency
obviously.

Signed-off-by: Lin Huang 
---
Changes in v2:
- None
Changes in v3:
- None

 drivers/devfreq/rk3399_dmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 5a2da95..39f8e27 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -329,7 +329,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
devm_devfreq_register_opp_notifier(dev, data->devfreq);
-
+   devfreq_opp_get_suspend_opp(dev, data->devfreq);
data->dev = dev;
platform_set_drvdata(pdev, data);
pd_register_notify_to_dmc(data->devfreq);
-- 
1.9.1

[RESEND PATCH v3 1/2] PM/devfreq: add suspend frequency support

[Lin Huang]

Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).

Signed-off-by: Lin Huang 
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 include/linux/devfreq.h   |  8 
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..4c76e79 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,8 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(>lock);
return;
}
-
-   devfreq_update_status(devfreq, devfreq->previous_freq);
+   if (devfreq->suspend_freq)
+   update_devfreq(devfreq);
+   else
+   devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(>lock);
cancel_delayed_work_sync(>work);
@@ -1254,6 +1256,18 @@ struct dev_pm_opp *devfreq_recommended_opp(struct device 
*dev,
 }
 EXPORT_SYMBOL(devfreq_recommended_opp);
 
+void devfreq_opp_get_suspend_opp(struct device *dev, struct devfreq *devfreq)
+{
+   struct dev_pm_opp *suspend_opp;
+
+   rcu_read_lock();
+   suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+   if (suspend_opp)
+   devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(devfreq_opp_get_suspend_opp);
+
 /**
  * devfreq_register_opp_notifier() - Helper function to get devfreq notified
  *for any changes in the OPP availability
diff --git a/drivers/devfreq/governor_simpleondemand.c 
b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..a3efee0 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
 
+   /*
+* if devfreq in suspend status and have suspend_freq,
+* the frequency need to set to suspend_freq
+*/
+   if (df->stop_polling && df->suspend_freq) {
+   *freq = df->suspend_freq;
+   return 0;
+   }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..1bdd5d3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
 
unsigned long previous_freq;
+   unsigned long suspend_freq;
struct devfreq_dev_status last_status;
 
void *data; /* private data for governors */
@@ -214,6 +215,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
 /* Helper functions for devfreq user device driver with OPP. */
 extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
   unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+   struct devfreq *devfreq);
 extern int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq);
 extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -315,6 +318,11 @@ static inline struct dev_pm_opp 
*devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
 }
 
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+  struct devfreq *devfreq)
+{
+}
+
 static inline int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq)
 {
-- 
1.9.1

[RESEND PATCH v3 2/2] PM/devfreq: rk3399: get devfreq suspend frequency

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop
working. For example: if we enable two monitor, then we will
stop ddr dvfs, but we hope ddr can run in highest frequency
obviously.

Signed-off-by: Lin Huang 
---
Changes in v2:
- None
Changes in v3:
- None

 drivers/devfreq/rk3399_dmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 5a2da95..39f8e27 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -329,7 +329,7 @@ static int rk3399_dmcfreq_probe(struct platform_device 
*pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
devm_devfreq_register_opp_notifier(dev, data->devfreq);
-
+   devfreq_opp_get_suspend_opp(dev, data->devfreq);
data->dev = dev;
platform_set_drvdata(pdev, data);
pd_register_notify_to_dmc(data->devfreq);
-- 
1.9.1

[RESEND PATCH v3 1/2] PM/devfreq: add suspend frequency support

[Lin Huang]

Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).

Signed-off-by: Lin Huang 
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 include/linux/devfreq.h   |  8 
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..4c76e79 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,8 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(>lock);
return;
}
-
-   devfreq_update_status(devfreq, devfreq->previous_freq);
+   if (devfreq->suspend_freq)
+   update_devfreq(devfreq);
+   else
+   devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(>lock);
cancel_delayed_work_sync(>work);
@@ -1254,6 +1256,18 @@ struct dev_pm_opp *devfreq_recommended_opp(struct device 
*dev,
 }
 EXPORT_SYMBOL(devfreq_recommended_opp);
 
+void devfreq_opp_get_suspend_opp(struct device *dev, struct devfreq *devfreq)
+{
+   struct dev_pm_opp *suspend_opp;
+
+   rcu_read_lock();
+   suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+   if (suspend_opp)
+   devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(devfreq_opp_get_suspend_opp);
+
 /**
  * devfreq_register_opp_notifier() - Helper function to get devfreq notified
  *for any changes in the OPP availability
diff --git a/drivers/devfreq/governor_simpleondemand.c 
b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..a3efee0 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
 
+   /*
+* if devfreq in suspend status and have suspend_freq,
+* the frequency need to set to suspend_freq
+*/
+   if (df->stop_polling && df->suspend_freq) {
+   *freq = df->suspend_freq;
+   return 0;
+   }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..1bdd5d3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
 
unsigned long previous_freq;
+   unsigned long suspend_freq;
struct devfreq_dev_status last_status;
 
void *data; /* private data for governors */
@@ -214,6 +215,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
 /* Helper functions for devfreq user device driver with OPP. */
 extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
   unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+   struct devfreq *devfreq);
 extern int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq);
 extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -315,6 +318,11 @@ static inline struct dev_pm_opp 
*devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
 }
 
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+  struct devfreq *devfreq)
+{
+}
+
 static inline int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq)
 {
-- 
1.9.1

[RESEND PATCH v3 0/2] set specific ddr frequency when stop ddr dvfs

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop working. So we
implement get suspend frequency function in devfreq framework, and call
it in rk3399 dmc driver. 

Lin Huang (2):
  PM/devfreq: add suspend frequency support
  PM/devfreq: rk3399: get devfreq suspend frequency

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 drivers/devfreq/rk3399_dmc.c  |  2 +-
 include/linux/devfreq.h   |  8 
 4 files changed, 34 insertions(+), 3 deletions(-)

-- 
1.9.1

[RESEND PATCH v3 0/2] set specific ddr frequency when stop ddr dvfs

[Lin Huang]

We need ddr run a specific frequency when ddr dvfs stop working. So we
implement get suspend frequency function in devfreq framework, and call
it in rk3399 dmc driver. 

Lin Huang (2):
  PM/devfreq: add suspend frequency support
  PM/devfreq: rk3399: get devfreq suspend frequency

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 drivers/devfreq/rk3399_dmc.c  |  2 +-
 include/linux/devfreq.h   |  8 
 4 files changed, 34 insertions(+), 3 deletions(-)

-- 
1.9.1

Re: -fno-PIE, take #3

[Theodore Ts'o]

On Fri, Nov 04, 2016 at 07:39:37PM +0100, Sebastian Andrzej Siewior wrote:
> Debian gcc's is nowdays compiled with --enable-default-pie which means it does
> -fPIE by default. This breaks atleast x86-64 compiles.
> This is the third attempt to fix it, this time by using runtime detection of
> the -fno-PIE compiler switch (it was introduced in gcc 3.4, min required gcc 
> is
> currently 3.2) so it can be backported to the stable kernels.
> As noted by Al this won't fix `git bisect' of stable kernels prio this commit.
> However using always a wrapper around gcc which adds -fno-PIE is not sollution
> I want to rely in future.

A wrapper around gcc which adds -fno-PIE doesn't work for the HOSTCC
builds, anyway:

% gcc -fno-PIE -o /tmp/hello /tmp/hello.c
/usr/bin/ld: /tmp/cckzDf9X.o: relocation R_X86_64_32 against `.rodata' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

Alas, the only workaround I've found which doesn't involve bisecting
the kernel is to add "CC=gcc-5" to the Makefile invocation (assuming
gcc-5 is installed of course).

- Ted

Re: -fno-PIE, take #3

[Theodore Ts'o]

On Fri, Nov 04, 2016 at 07:39:37PM +0100, Sebastian Andrzej Siewior wrote:
> Debian gcc's is nowdays compiled with --enable-default-pie which means it does
> -fPIE by default. This breaks atleast x86-64 compiles.
> This is the third attempt to fix it, this time by using runtime detection of
> the -fno-PIE compiler switch (it was introduced in gcc 3.4, min required gcc 
> is
> currently 3.2) so it can be backported to the stable kernels.
> As noted by Al this won't fix `git bisect' of stable kernels prio this commit.
> However using always a wrapper around gcc which adds -fno-PIE is not sollution
> I want to rely in future.

A wrapper around gcc which adds -fno-PIE doesn't work for the HOSTCC
builds, anyway:

% gcc -fno-PIE -o /tmp/hello /tmp/hello.c
/usr/bin/ld: /tmp/cckzDf9X.o: relocation R_X86_64_32 against `.rodata' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

Alas, the only workaround I've found which doesn't involve bisecting
the kernel is to add "CC=gcc-5" to the Makefile invocation (assuming
gcc-5 is installed of course).

- Ted

Re: [PATCH v6 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote:
> From: Joonsoo Kim 
> 
> Hello,
> 
> Changes from v5
> o Add acked/reviewed-by tag from Vlastimil and Aneesh
> o Rebase on next-20161013
> o Cosmetic change on patch 1
> o Optimize span of ZONE_CMA on multiple node system

Hello, Andrew.

I got some acked/reviewed-by tags from some of main MM developers who
are actually familiar/associated with this change. Could you merge
this patchset to your tree to get more test coverage?

If I need to do more things to merge this patchset, please let me know
about it.

Thanks.

Re: [PATCH v6 0/6] Introduce ZONE_CMA

[Joonsoo Kim]

On Fri, Oct 14, 2016 at 12:03:10PM +0900, js1...@gmail.com wrote:
> From: Joonsoo Kim 
> 
> Hello,
> 
> Changes from v5
> o Add acked/reviewed-by tag from Vlastimil and Aneesh
> o Rebase on next-20161013
> o Cosmetic change on patch 1
> o Optimize span of ZONE_CMA on multiple node system

Hello, Andrew.

I got some acked/reviewed-by tags from some of main MM developers who
are actually familiar/associated with this change. Could you merge
this patchset to your tree to get more test coverage?

If I need to do more things to merge this patchset, please let me know
about it.

Thanks.

[PATCH v3 1/2] PM/devfreq: add suspend frequency support

[Lin Huang]

Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).

Signed-off-by: Lin Huang 
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 include/linux/devfreq.h   |  8 
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..4c76e79 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,8 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(>lock);
return;
}
-
-   devfreq_update_status(devfreq, devfreq->previous_freq);
+   if (devfreq->suspend_freq)
+   update_devfreq(devfreq);
+   else
+   devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(>lock);
cancel_delayed_work_sync(>work);
@@ -1254,6 +1256,18 @@ struct dev_pm_opp *devfreq_recommended_opp(struct device 
*dev,
 }
 EXPORT_SYMBOL(devfreq_recommended_opp);
 
+void devfreq_opp_get_suspend_opp(struct device *dev, struct devfreq *devfreq)
+{
+   struct dev_pm_opp *suspend_opp;
+
+   rcu_read_lock();
+   suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+   if (suspend_opp)
+   devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(devfreq_opp_get_suspend_opp);
+
 /**
  * devfreq_register_opp_notifier() - Helper function to get devfreq notified
  *for any changes in the OPP availability
diff --git a/drivers/devfreq/governor_simpleondemand.c 
b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..a3efee0 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
 
+   /*
+* if devfreq in suspend status and have suspend_freq,
+* the frequency need to set to suspend_freq
+*/
+   if (df->stop_polling && df->suspend_freq) {
+   *freq = df->suspend_freq;
+   return 0;
+   }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..1bdd5d3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
 
unsigned long previous_freq;
+   unsigned long suspend_freq;
struct devfreq_dev_status last_status;
 
void *data; /* private data for governors */
@@ -214,6 +215,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
 /* Helper functions for devfreq user device driver with OPP. */
 extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
   unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+   struct devfreq *devfreq);
 extern int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq);
 extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -315,6 +318,11 @@ static inline struct dev_pm_opp 
*devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
 }
 
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+  struct devfreq *devfreq)
+{
+}
+
 static inline int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq)
 {
-- 
1.9.1

[PATCH v3 1/2] PM/devfreq: add suspend frequency support

[Lin Huang]

Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).

Signed-off-by: Lin Huang 
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error

 drivers/devfreq/devfreq.c | 18 --
 drivers/devfreq/governor_simpleondemand.c |  9 +
 include/linux/devfreq.h   |  8 
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..4c76e79 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,8 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(>lock);
return;
}
-
-   devfreq_update_status(devfreq, devfreq->previous_freq);
+   if (devfreq->suspend_freq)
+   update_devfreq(devfreq);
+   else
+   devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(>lock);
cancel_delayed_work_sync(>work);
@@ -1254,6 +1256,18 @@ struct dev_pm_opp *devfreq_recommended_opp(struct device 
*dev,
 }
 EXPORT_SYMBOL(devfreq_recommended_opp);
 
+void devfreq_opp_get_suspend_opp(struct device *dev, struct devfreq *devfreq)
+{
+   struct dev_pm_opp *suspend_opp;
+
+   rcu_read_lock();
+   suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+   if (suspend_opp)
+   devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+   rcu_read_unlock();
+}
+EXPORT_SYMBOL(devfreq_opp_get_suspend_opp);
+
 /**
  * devfreq_register_opp_notifier() - Helper function to get devfreq notified
  *for any changes in the OPP availability
diff --git a/drivers/devfreq/governor_simpleondemand.c 
b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..a3efee0 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
 
+   /*
+* if devfreq in suspend status and have suspend_freq,
+* the frequency need to set to suspend_freq
+*/
+   if (df->stop_polling && df->suspend_freq) {
+   *freq = df->suspend_freq;
+   return 0;
+   }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..1bdd5d3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
 
unsigned long previous_freq;
+   unsigned long suspend_freq;
struct devfreq_dev_status last_status;
 
void *data; /* private data for governors */
@@ -214,6 +215,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
 /* Helper functions for devfreq user device driver with OPP. */
 extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
   unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+   struct devfreq *devfreq);
 extern int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq);
 extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -315,6 +318,11 @@ static inline struct dev_pm_opp 
*devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
 }
 
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+  struct devfreq *devfreq)
+{
+}
+
 static inline int devfreq_register_opp_notifier(struct device *dev,
 struct devfreq *devfreq)
 {
-- 
1.9.1

arm: why set MIN_GAP to 128M size

[Chenjie (K)]

Hi everyone
arm:

/* gap between mmap and stack */
#define MIN_GAP (128*1024*1024UL)

The min_gap is 128M,
in the mmap_base function
unsigned long gap = rlimit(RLIMIT_STACK);

if (gap < MIN_GAP)
gap = MIN_GAP;
else if (gap > MAX_GAP)
gap = MAX_GAP;

I can not use the "128-stack_size"(M)

can i modify it to 64M?


Thanks,
jie chen

Re: [PATCH v11 00/22] Add Mediated device support

[Alexey Kardashevskiy]

On 07/11/16 14:59, Kirti Wankhede wrote:
> 
> 
> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
>> On 05/11/16 08:10, Kirti Wankhede wrote:
>>> This series adds Mediated device support to Linux host kernel. Purpose
>>> of this series is to provide a common interface for mediated device
>>> management that can be used by different devices. This series introduces
>>> Mdev core module that creates and manages mediated devices, VFIO based
>>> driver for mediated devices that are created by mdev core module and
>>> update VFIO type1 IOMMU module to support pinning & unpinning for mediated
>>> devices.
>>>
>>> What changed in v11?
>>> mdev core:
>>>   Register mdev_bus class when first device is registed to avoid panic if
>>>   any vendor driver and mdev driver are selected as built-in but vendor
>>>   driver loads first and then mdev module.
>>> vfio_mdev:
>>>   Added notifier callback function to mdev parent's ops so that notifer
>>>   is registered from vfio_mdev module during device open and unregistered
>>>   it from device close call. This is a optional callback. Some drivers
>>>   using mdev framework might not pin or unpin pages, for example the
>>>   sample mtty driver that simulates serial port. Vendor driver who need to
>>>   pin/unpin pages should provide this callback. Otherwise pin request
>>>   would fail.
>>> vfio_iommu_type1:
>>>   Updated to keep track of who (task and address space) mapped iova range.
>>>   During DMA_UNMAP, same task who mapped it or other task who shares same
>>>   address space is allowed to unmap, otherwise unmap fails.
>>>   QEMU maps few iova ranges initially, then fork threads and from the child
>>>   thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>>   address space, DMA_UNMAP is successful.
>>>   Address space keeps track of pages pinned (pfn_list) by external user /
>>>   mdev devices. This pfn_list is used to verify pfn during unpin_request,
>>>   re-accounting of pages when direct device assigned in hot-unplugged and
>>>   mdev device is present in same container.
>>>   When the container is released, all mapped iova from all tasks are
>>>   unmapped and removed.
>>>
>>>   Tested by assigning below combinations of devices to a single VM:
>>>- GPU pass through only
>>>- vGPU device only
>>>- One GPU pass through and one vGPU device
>>>- Linux VM hot plug and unplug vGPU device while GPU pass through device
>>>  exist
>>>- Linux VM hot plug and unplug GPU pass through device while vGPU device
>>>  exist
>>>
>>>   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
>>>   Resolved against conflicting change:
>>
>> Patch 11/22 does not apply if the patchset is applied on top of 14970f204b19.
>>
>>
> 
> Pull commit 05692d7005a3 (below) commit.

Nah, it was my fault, thunderbird's plugin saved mails in wrong order,
false alarm, sorry.

Speaking of order, 11/22 is better be squashed into 02/22 (as it does not
seem to make sense alone; it also does not depend on something between
02/22 and 11/22); and both 01/22 and 02/22 better be moved where "docs"
patches start as they do not makes sense earlier anyway, or do they?



> 
>>
>>>   05692d7005a3 vfio/pci: Fix integer overflows, bitmask check
>>>
> 
> Thanks,
> Kirti
> 
>>>
>>> Kirti Wankhede (22):
>>>   vfio: Mediated device Core driver
>>>   vfio: VFIO based driver for Mediated devices
>>>   vfio: Rearrange functions to get vfio_group from dev
>>>   vfio: Common function to increment container_users
>>>   vfio iommu: Added pin and unpin callback functions to
>>> vfio_iommu_driver_ops
>>>   vfio iommu type1: Update arguments of vfio_lock_acct
>>>   vfio iommu type1: Update argument of vaddr_get_pfn()
>>>   vfio iommu type1: Add find_iommu_group() function
>>>   vfio iommu type1: Add task structure to vfio_dma
>>>   vfio iommu type1: Add support for mediated devices
>>>   vfio iommu: Add blocking notifier to notify DMA_UNMAP
>>>   vfio: Add notifier callback to parent's ops structure of mdev
>>>   vfio: Introduce common function to add capabilities
>>>   vfio_pci: Update vfio_pci to use vfio_info_add_capability()
>>>   vfio: Introduce vfio_set_irqs_validate_and_prepare()
>>>   vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio_platform: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio: Define device_api strings
>>>   docs: Add Documentation for Mediated devices
>>>   docs: Sysfs ABI for mediated device framework
>>>   docs: Sample driver to demonstrate how to use Mediated device
>>> framework.
>>>   MAINTAINERS: Add entry VFIO based Mediated device drivers
>>>
>>>  Documentation/ABI/testing/sysfs-bus-vfio-mdev |  111 ++
>>>  Documentation/vfio-mediated-device.txt|  399 +++
>>>  MAINTAINERS   |9 +
>>>  drivers/vfio/Kconfig  |1 +
>>>  drivers/vfio/Makefile |1 +
>>>  drivers/vfio/mdev/Kconfig 

arm: why set MIN_GAP to 128M size

[Chenjie (K)]

Hi everyone
arm:

/* gap between mmap and stack */
#define MIN_GAP (128*1024*1024UL)

The min_gap is 128M,
in the mmap_base function
unsigned long gap = rlimit(RLIMIT_STACK);

if (gap < MIN_GAP)
gap = MIN_GAP;
else if (gap > MAX_GAP)
gap = MAX_GAP;

I can not use the "128-stack_size"(M)

can i modify it to 64M?


Thanks,
jie chen

Re: [PATCH v11 00/22] Add Mediated device support

[Alexey Kardashevskiy]

On 07/11/16 14:59, Kirti Wankhede wrote:
> 
> 
> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
>> On 05/11/16 08:10, Kirti Wankhede wrote:
>>> This series adds Mediated device support to Linux host kernel. Purpose
>>> of this series is to provide a common interface for mediated device
>>> management that can be used by different devices. This series introduces
>>> Mdev core module that creates and manages mediated devices, VFIO based
>>> driver for mediated devices that are created by mdev core module and
>>> update VFIO type1 IOMMU module to support pinning & unpinning for mediated
>>> devices.
>>>
>>> What changed in v11?
>>> mdev core:
>>>   Register mdev_bus class when first device is registed to avoid panic if
>>>   any vendor driver and mdev driver are selected as built-in but vendor
>>>   driver loads first and then mdev module.
>>> vfio_mdev:
>>>   Added notifier callback function to mdev parent's ops so that notifer
>>>   is registered from vfio_mdev module during device open and unregistered
>>>   it from device close call. This is a optional callback. Some drivers
>>>   using mdev framework might not pin or unpin pages, for example the
>>>   sample mtty driver that simulates serial port. Vendor driver who need to
>>>   pin/unpin pages should provide this callback. Otherwise pin request
>>>   would fail.
>>> vfio_iommu_type1:
>>>   Updated to keep track of who (task and address space) mapped iova range.
>>>   During DMA_UNMAP, same task who mapped it or other task who shares same
>>>   address space is allowed to unmap, otherwise unmap fails.
>>>   QEMU maps few iova ranges initially, then fork threads and from the child
>>>   thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>>   address space, DMA_UNMAP is successful.
>>>   Address space keeps track of pages pinned (pfn_list) by external user /
>>>   mdev devices. This pfn_list is used to verify pfn during unpin_request,
>>>   re-accounting of pages when direct device assigned in hot-unplugged and
>>>   mdev device is present in same container.
>>>   When the container is released, all mapped iova from all tasks are
>>>   unmapped and removed.
>>>
>>>   Tested by assigning below combinations of devices to a single VM:
>>>- GPU pass through only
>>>- vGPU device only
>>>- One GPU pass through and one vGPU device
>>>- Linux VM hot plug and unplug vGPU device while GPU pass through device
>>>  exist
>>>- Linux VM hot plug and unplug GPU pass through device while vGPU device
>>>  exist
>>>
>>>   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
>>>   Resolved against conflicting change:
>>
>> Patch 11/22 does not apply if the patchset is applied on top of 14970f204b19.
>>
>>
> 
> Pull commit 05692d7005a3 (below) commit.

Nah, it was my fault, thunderbird's plugin saved mails in wrong order,
false alarm, sorry.

Speaking of order, 11/22 is better be squashed into 02/22 (as it does not
seem to make sense alone; it also does not depend on something between
02/22 and 11/22); and both 01/22 and 02/22 better be moved where "docs"
patches start as they do not makes sense earlier anyway, or do they?



> 
>>
>>>   05692d7005a3 vfio/pci: Fix integer overflows, bitmask check
>>>
> 
> Thanks,
> Kirti
> 
>>>
>>> Kirti Wankhede (22):
>>>   vfio: Mediated device Core driver
>>>   vfio: VFIO based driver for Mediated devices
>>>   vfio: Rearrange functions to get vfio_group from dev
>>>   vfio: Common function to increment container_users
>>>   vfio iommu: Added pin and unpin callback functions to
>>> vfio_iommu_driver_ops
>>>   vfio iommu type1: Update arguments of vfio_lock_acct
>>>   vfio iommu type1: Update argument of vaddr_get_pfn()
>>>   vfio iommu type1: Add find_iommu_group() function
>>>   vfio iommu type1: Add task structure to vfio_dma
>>>   vfio iommu type1: Add support for mediated devices
>>>   vfio iommu: Add blocking notifier to notify DMA_UNMAP
>>>   vfio: Add notifier callback to parent's ops structure of mdev
>>>   vfio: Introduce common function to add capabilities
>>>   vfio_pci: Update vfio_pci to use vfio_info_add_capability()
>>>   vfio: Introduce vfio_set_irqs_validate_and_prepare()
>>>   vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio_platform: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio: Define device_api strings
>>>   docs: Add Documentation for Mediated devices
>>>   docs: Sysfs ABI for mediated device framework
>>>   docs: Sample driver to demonstrate how to use Mediated device
>>> framework.
>>>   MAINTAINERS: Add entry VFIO based Mediated device drivers
>>>
>>>  Documentation/ABI/testing/sysfs-bus-vfio-mdev |  111 ++
>>>  Documentation/vfio-mediated-device.txt|  399 +++
>>>  MAINTAINERS   |9 +
>>>  drivers/vfio/Kconfig  |1 +
>>>  drivers/vfio/Makefile |1 +
>>>  drivers/vfio/mdev/Kconfig 

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Joonsoo Kim]

On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> Hello, I hava a question on cma zone.
> 
> When we have cma zone, cma zone will be the highest zone of system.
> 
> In android system, the most memory allocator is ION. Media system will
> alloc unmovable memory from it.
> 
> On low memory scene, will the CMA zone always do balance?

Allocation request for low zone (normal zone) would not cause CMA zone
to be balanced since it isn't helpful.

> Should we transmit the highest available zone to kswapd？

It is already done when necessary.

Thanks.

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Joonsoo Kim]

On Tue, Nov 01, 2016 at 03:58:32PM +0800, Chen Feng wrote:
> Hello, I hava a question on cma zone.
> 
> When we have cma zone, cma zone will be the highest zone of system.
> 
> In android system, the most memory allocator is ION. Media system will
> alloc unmovable memory from it.
> 
> On low memory scene, will the CMA zone always do balance?

Allocation request for low zone (normal zone) would not cause CMA zone
to be balanced since it isn't helpful.

> Should we transmit the highest available zone to kswapd？

It is already done when necessary.

Thanks.

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

[Viresh Kumar]

For the record, I have never got the original mail with this subject.

On 06-11-16, 11:19, Stratos Karafotis wrote:
> Conservative governor changes the CPU frequency in steps.
> That means that if a CPU runs at max frequency, it will need several
> sampling periods to return at min frequency when the workload
> is finished.
> 
> If the timer that calculates the load and target frequency is deferred,
> the governor might need even more time to decrease the frequency.
> 
> This may have impact to power consumption and after all conservative
> should decrease the frequency if there is no workload every sampling
> rate.
> 
> To resolve the above issue calculate the number of sampling periods
> that the timer deferred. Considering that for each sampling period
> conservative should drop the frequency by a freq_step because the
> CPU was idle apply the proper subtraction to requested frequency.
> 
> Below, the kernel trace with and without this patch. First an
> intensive workload is applied on a specific CPU. Then the workload
> is removed and the CPU goes to idle.
> 
> WITHOUT
> ---
>  -0 [007] dN..   620.329153: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    620.350857: cpu_frequency: state=170 
> cpu_id=7
> kworker/7:2-556   [007]    620.370856: cpu_frequency: state=190 
> cpu_id=7
> kworker/7:2-556   [007]    620.390854: cpu_frequency: state=210 
> cpu_id=7
> kworker/7:2-556   [007]    620.411853: cpu_frequency: state=220 
> cpu_id=7
> kworker/7:2-556   [007]    620.432854: cpu_frequency: state=240 
> cpu_id=7
> kworker/7:2-556   [007]    620.453854: cpu_frequency: state=260 
> cpu_id=7
> kworker/7:2-556   [007]    620.494856: cpu_frequency: state=290 
> cpu_id=7
> kworker/7:2-556   [007]    620.515856: cpu_frequency: state=310 
> cpu_id=7
> kworker/7:2-556   [007]    620.536858: cpu_frequency: state=330 
> cpu_id=7
> kworker/7:2-556   [007]    620.557857: cpu_frequency: state=3401000 
> cpu_id=7
>  -0 [007] d...   669.591363: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   669.591939: cpu_idle: state=4294967295 cpu_id=7
>  -0 [007] d...   669.591980: cpu_idle: state=4 cpu_id=7
>  -0 [007] dN..   669.591989: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   670.201224: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   670.221975: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    670.222016: cpu_frequency: state=330 
> cpu_id=7
>  -0 [007] d...   670.222026: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   670.234964: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   670.801251: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.236046: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    671.236073: cpu_frequency: state=310 
> cpu_id=7
>  -0 [007] d...   671.236112: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.393437: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   671.401277: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.404083: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    671.404111: cpu_frequency: state=290 
> cpu_id=7
>  -0 [007] d...   671.404125: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.404974: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   671.501180: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.995414: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    671.995459: cpu_frequency: state=280 
> cpu_id=7
>  -0 [007] d...   671.995469: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.996287: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   672.001305: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.078374: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.078410: cpu_frequency: state=260 
> cpu_id=7
>  -0 [007] d...   672.078419: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.158020: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.158040: cpu_frequency: state=240 
> cpu_id=7
>  -0 [007] d...   672.158044: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.160038: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   672.234557: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.237121: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.237174: cpu_frequency: state=210 
> cpu_id=7
>  -0 [007] d...   672.237186: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.237778: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   672.267902: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.269860: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.269906: cpu_frequency: 

Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

[Viresh Kumar]

For the record, I have never got the original mail with this subject.

On 06-11-16, 11:19, Stratos Karafotis wrote:
> Conservative governor changes the CPU frequency in steps.
> That means that if a CPU runs at max frequency, it will need several
> sampling periods to return at min frequency when the workload
> is finished.
> 
> If the timer that calculates the load and target frequency is deferred,
> the governor might need even more time to decrease the frequency.
> 
> This may have impact to power consumption and after all conservative
> should decrease the frequency if there is no workload every sampling
> rate.
> 
> To resolve the above issue calculate the number of sampling periods
> that the timer deferred. Considering that for each sampling period
> conservative should drop the frequency by a freq_step because the
> CPU was idle apply the proper subtraction to requested frequency.
> 
> Below, the kernel trace with and without this patch. First an
> intensive workload is applied on a specific CPU. Then the workload
> is removed and the CPU goes to idle.
> 
> WITHOUT
> ---
>  -0 [007] dN..   620.329153: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    620.350857: cpu_frequency: state=170 
> cpu_id=7
> kworker/7:2-556   [007]    620.370856: cpu_frequency: state=190 
> cpu_id=7
> kworker/7:2-556   [007]    620.390854: cpu_frequency: state=210 
> cpu_id=7
> kworker/7:2-556   [007]    620.411853: cpu_frequency: state=220 
> cpu_id=7
> kworker/7:2-556   [007]    620.432854: cpu_frequency: state=240 
> cpu_id=7
> kworker/7:2-556   [007]    620.453854: cpu_frequency: state=260 
> cpu_id=7
> kworker/7:2-556   [007]    620.494856: cpu_frequency: state=290 
> cpu_id=7
> kworker/7:2-556   [007]    620.515856: cpu_frequency: state=310 
> cpu_id=7
> kworker/7:2-556   [007]    620.536858: cpu_frequency: state=330 
> cpu_id=7
> kworker/7:2-556   [007]    620.557857: cpu_frequency: state=3401000 
> cpu_id=7
>  -0 [007] d...   669.591363: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   669.591939: cpu_idle: state=4294967295 cpu_id=7
>  -0 [007] d...   669.591980: cpu_idle: state=4 cpu_id=7
>  -0 [007] dN..   669.591989: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   670.201224: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   670.221975: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    670.222016: cpu_frequency: state=330 
> cpu_id=7
>  -0 [007] d...   670.222026: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   670.234964: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   670.801251: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.236046: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    671.236073: cpu_frequency: state=310 
> cpu_id=7
>  -0 [007] d...   671.236112: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.393437: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   671.401277: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.404083: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    671.404111: cpu_frequency: state=290 
> cpu_id=7
>  -0 [007] d...   671.404125: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.404974: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   671.501180: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.995414: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    671.995459: cpu_frequency: state=280 
> cpu_id=7
>  -0 [007] d...   671.995469: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   671.996287: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   672.001305: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.078374: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.078410: cpu_frequency: state=260 
> cpu_id=7
>  -0 [007] d...   672.078419: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.158020: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.158040: cpu_frequency: state=240 
> cpu_id=7
>  -0 [007] d...   672.158044: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.160038: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   672.234557: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.237121: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.237174: cpu_frequency: state=210 
> cpu_id=7
>  -0 [007] d...   672.237186: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.237778: cpu_idle: state=4294967295 cpu_id=7
> ...
>  -0 [007] d...   672.267902: cpu_idle: state=4 cpu_id=7
>  -0 [007] d...   672.269860: cpu_idle: state=4294967295 cpu_id=7
> kworker/7:2-556   [007]    672.269906: cpu_frequency: 

Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads

[Laxman Dewangan]

On Saturday 05 November 2016 03:54 AM, Linus Walleij wrote:

On Wed, Nov 2, 2016 at 10:09 AM, Laxman Dewangan  wrote:


NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO power rail sources. When IO
interface are not used then IO pads can be configure in low power
state to reduce the power from that IO pads.

On Tegra124, the IO power rail source is auto detected by SoC and hence
it is only require to configure in low power mode if IO pads are not
used.

On T210 onwards, the auto-detection is removed from SoC and hence SW
must configure the PMC register explicitly to set proper voltage in
IO pads based on IO rail power source voltage.

This driver adds the IO pad driver to configure the power state and
IO pad voltage based on the usage and power tree via pincontrol
framework. The configuration can be static and dynamic.

Signed-off-by: Laxman Dewangan 

Looking for an ACK from Stephen &| Thierry.


This driver depends on some new APIs from tegra pmc driver. The new APIs 
are integrated in Thierry's branch and he wanted to push the changes to 
linux-next/main path if there is any client driver for this.


This series is the client driver for tegra PMC.

So if you are fine, then you can ACK and Thierry can take this in his 
branch.


Or I will leave to you/Thierry to propose if some other idea for 
discussion/acceptance.





---
On top of the branch from Thierry's T186 work
 https://github.com/thierryreding/linux/tree/tegra186

But it's an orthogonal patch right?

The build robot seems to have problems with it so pls fix these.
The driver built in pinctrl branch and so this is expected. The APIs are 
in the above branch.





+static const struct pinconf_generic_params tegra_io_pads_cfg_params[] = {
+   {
+   .property = "nvidia,power-source-voltage",
+   .param = TEGRA_IO_PAD_POWER_SOURCE_VOLTAGE,
+   },
+};

Why can you not use the standard power-source binding
from Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
instead of inventing this nvidia,* variant?


Per binding doc,
power-source- select between different power supplies

So actually it selects the different source of power supply.
In my case, I will have same supply but voltage of that supply get changed.
So here property is for the power-supply-voltage.

Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads

[Laxman Dewangan]

On Saturday 05 November 2016 03:54 AM, Linus Walleij wrote:

On Wed, Nov 2, 2016 at 10:09 AM, Laxman Dewangan  wrote:


NVIDIA Tegra124 and later SoCs support the multi-voltage level and
low power state of some of its IO pads. The IO pads can work in
the voltage of the 1.8V and 3.3V of IO power rail sources. When IO
interface are not used then IO pads can be configure in low power
state to reduce the power from that IO pads.

On Tegra124, the IO power rail source is auto detected by SoC and hence
it is only require to configure in low power mode if IO pads are not
used.

On T210 onwards, the auto-detection is removed from SoC and hence SW
must configure the PMC register explicitly to set proper voltage in
IO pads based on IO rail power source voltage.

This driver adds the IO pad driver to configure the power state and
IO pad voltage based on the usage and power tree via pincontrol
framework. The configuration can be static and dynamic.

Signed-off-by: Laxman Dewangan 

Looking for an ACK from Stephen &| Thierry.


This driver depends on some new APIs from tegra pmc driver. The new APIs 
are integrated in Thierry's branch and he wanted to push the changes to 
linux-next/main path if there is any client driver for this.


This series is the client driver for tegra PMC.

So if you are fine, then you can ACK and Thierry can take this in his 
branch.


Or I will leave to you/Thierry to propose if some other idea for 
discussion/acceptance.





---
On top of the branch from Thierry's T186 work
 https://github.com/thierryreding/linux/tree/tegra186

But it's an orthogonal patch right?

The build robot seems to have problems with it so pls fix these.
The driver built in pinctrl branch and so this is expected. The APIs are 
in the above branch.





+static const struct pinconf_generic_params tegra_io_pads_cfg_params[] = {
+   {
+   .property = "nvidia,power-source-voltage",
+   .param = TEGRA_IO_PAD_POWER_SOURCE_VOLTAGE,
+   },
+};

Why can you not use the standard power-source binding
from Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
instead of inventing this nvidia,* variant?


Per binding doc,
power-source- select between different power supplies

So actually it selects the different source of power supply.
In my case, I will have same supply but voltage of that supply get changed.
So here property is for the power-supply-voltage.

Re: [PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event

[Binoy Jayan]

Hi Linus,

On 3 November 2016 at 21:07, Linus Torvalds
 wrote:
> This is wrong.

Will change it back.

> Since that "umr_context" variable is on the stack, and you are waiting
> for it to be fully done, it really should be a completion.

Thank you for sharing your insight with wait_event and completion.

-Binoy

Re: [PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event

[Binoy Jayan]

Hi Linus,

On 3 November 2016 at 21:07, Linus Torvalds
 wrote:
> This is wrong.

Will change it back.

> Since that "umr_context" variable is on the stack, and you are waiting
> for it to be fully done, it really should be a completion.

Thank you for sharing your insight with wait_event and completion.

-Binoy

[patch v5 1/1] i2c: add master driver for mellanox systems

[vadimp]

From: Vadim Pasternak 

Device driver for Mellanox I2C controller logic, implemented in Lattice
CPLD device.
Device supports:
 - Master mode
 - One physical bus
 - Polling mode

The Kconfig currently controlling compilation of this code is:
drivers/i2c/busses/Kconfig:config I2C_MLXCPLD

Signed-off-by: Michael Shych 
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
Reviewed-by: Vladimir Zapolskiy 
---
v4->v5:
 Comments pointed out by Vladimir:
 - Remove "default n" from Kconfig;
 - Fix the comments for timeout and pool time;
 - Optimize error flow in mlxcpld_i2c_probe;
v3->v4:
 Comments pointed out by Vladimir:
 - Set default to no in Kconfig;
 - Make mlxcpld_i2c_plat_dev static and add empty line before the
   declaration;
 - In function mlxcpld_i2c_invalid_len remove (msg->len < 0), since len is
   unsigned;
 - Remove unused symbol mlxcpld_i2c_plat_dev;
 - Remove extra spaces in comments to mlxcpld_i2c_check_msg_params;
 - Remove unnecessary round braces in mlxcpld_i2c_set_transf_data;
 - Remove the assignment of 'i' variable in mlxcpld_i2c_wait_for_tc;
 - Add extra line in mlxcpld_i2c_xfer;
 - Move assignment of the adapter's fields retries and nr inside
   mlxcpld_i2c_adapter declaration;
v2->v3:
 Comments pointed out by Vladimir:
 - Use tab symbol as indentation in Kconfig
 - Add the Kconfig section preserving the alphabetical order - added
   within "Other I2C/SMBus bus drivers" after I2C_ELEKTOR (but after this
   sections others are not follow alphabetical);
 - Change license to dual;
 - Replace ADRR with ADDR in macros;
 - Remove unused macros: MLXCPLD_LPCI2C_LPF_DFLT,
   MLXCPLD_LPCI2C_HALF_CYC_100, MLXCPLD_LPCI2C_I2C_HOLD_100,
   MLXCPLD_LPCI2C_HALF_CYC_REG, MLXCPLD_LPCI2C_I2C_HOLD_REG;
 - Fix checkpatch warnings (**/ and the end of comment);
 - Add empty line before structures mlxcpld_i2c_regs,
   mlxcpld_i2c_curr_transf, mlxcpld_i2c_priv;
 - Remove unused structure mlxcpld_i2c_regs;
 - Remove from mlxcpld_i2c_priv the next fields:
   retr_num, poll_time, block_sz, xfer_to; use instead macros
   respectively: MLXCPLD_I2C_RETR_NUM, MLXCPLD_I2C_POLL_TIME,
   MLXCPLD_I2C_DATA_REG_SZ, MLXCPLD_I2C_XFER_TO;
 - In mlxcpld_i2c_invalid_len remove unnecessary else;
 - Optimize mlxcpld_i2c_set_transf_data;
 - mlxcpld_i2c_reset - add empty lines after/before mutex
   lock/unlock;
 - mlxcpld_i2c_wait_for_free - cover case timeout is equal
   MLXCPLD_I2C_XFER_TO;
 - mlxcpld_i2c_wait_for_tc:
   - Do not assign err in declaration (also err is removed);
   - Insert empty line before case MLXCPLD_LPCI2C_ACK_IND;
   - inside case MLXCPLD_LPCI2C_ACK_IND - avoid unnecessary
 indentation;
   - Remove case MLXCPLD_LPCI2C_ERR_IND and remove this macro;
 - Add empty lines in mlxcpld_i2c_xfer before/after mutex_lock/
   mutex_unlock;
 - In mlxcpld_i2c_probe add emtpy line after platform_set_drvdata;
 - Replace platfrom handle pdev in mlxcpld_i2c_priv with the pointer
   to the structure device;
 - Place assignment of base_addr near the others;
 - Enclose e-mail with <>;
 Fixes added by Vadim:
 - Change structure description format according to
   Documentation/kernel-documentation.rst guideline;
 - mlxcpld_i2c_wait_for_tc: return error if status reaches default case;
v1->v2
 Fixes added by Vadim:
 - Put new record in Makefile in alphabetic order;
 - Remove http://www.mellanox.com from MAINTAINERS record;
---
 Documentation/i2c/busses/i2c-mlxcpld |  47 +++
 MAINTAINERS  |   8 +
 drivers/i2c/busses/Kconfig   |  11 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-mlxcpld.c | 551 +++
 5 files changed, 618 insertions(+)
 create mode 100644 Documentation/i2c/busses/i2c-mlxcpld
 create mode 100644 drivers/i2c/busses/i2c-mlxcpld.c

diff --git a/Documentation/i2c/busses/i2c-mlxcpld 
b/Documentation/i2c/busses/i2c-mlxcpld
new file mode 100644
index 000..0f8678a
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-mlxcpld
@@ -0,0 +1,47 @@
+Driver i2c-mlxcpld
+
+Author: Michael Shych 
+
+This is a for Mellanox I2C controller logic, implemented in Lattice CPLD
+device.
+Device supports:
+ - Master mode.
+ - One physical bus.
+ - Polling mode.
+
+This controller is equipped within the next Mellanox systems:
+"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
+"msn2740", "msn2100".
+
+The next transaction types are supported:
+ - Receive Byte/Block.
+ - Send Byte/Block.
+ - Read Byte/Block.
+ - Write Byte/Block.
+
+Registers:
+CTRL   0x1 - control reg.
+   Resets all the registers.
+HALF_CYC   0x4 - cycle reg.
+   Configure the width of I2C SCL half clock cycle (in 4 
LPC_CLK
+   units).
+I2C_HOLD   0x5 - hold reg.
+   OE (output enable) is delayed by value set to this 
register
+

[patch v5 1/1] i2c: add master driver for mellanox systems

[vadimp]

From: Vadim Pasternak 

Device driver for Mellanox I2C controller logic, implemented in Lattice
CPLD device.
Device supports:
 - Master mode
 - One physical bus
 - Polling mode

The Kconfig currently controlling compilation of this code is:
drivers/i2c/busses/Kconfig:config I2C_MLXCPLD

Signed-off-by: Michael Shych 
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
Reviewed-by: Vladimir Zapolskiy 
---
v4->v5:
 Comments pointed out by Vladimir:
 - Remove "default n" from Kconfig;
 - Fix the comments for timeout and pool time;
 - Optimize error flow in mlxcpld_i2c_probe;
v3->v4:
 Comments pointed out by Vladimir:
 - Set default to no in Kconfig;
 - Make mlxcpld_i2c_plat_dev static and add empty line before the
   declaration;
 - In function mlxcpld_i2c_invalid_len remove (msg->len < 0), since len is
   unsigned;
 - Remove unused symbol mlxcpld_i2c_plat_dev;
 - Remove extra spaces in comments to mlxcpld_i2c_check_msg_params;
 - Remove unnecessary round braces in mlxcpld_i2c_set_transf_data;
 - Remove the assignment of 'i' variable in mlxcpld_i2c_wait_for_tc;
 - Add extra line in mlxcpld_i2c_xfer;
 - Move assignment of the adapter's fields retries and nr inside
   mlxcpld_i2c_adapter declaration;
v2->v3:
 Comments pointed out by Vladimir:
 - Use tab symbol as indentation in Kconfig
 - Add the Kconfig section preserving the alphabetical order - added
   within "Other I2C/SMBus bus drivers" after I2C_ELEKTOR (but after this
   sections others are not follow alphabetical);
 - Change license to dual;
 - Replace ADRR with ADDR in macros;
 - Remove unused macros: MLXCPLD_LPCI2C_LPF_DFLT,
   MLXCPLD_LPCI2C_HALF_CYC_100, MLXCPLD_LPCI2C_I2C_HOLD_100,
   MLXCPLD_LPCI2C_HALF_CYC_REG, MLXCPLD_LPCI2C_I2C_HOLD_REG;
 - Fix checkpatch warnings (**/ and the end of comment);
 - Add empty line before structures mlxcpld_i2c_regs,
   mlxcpld_i2c_curr_transf, mlxcpld_i2c_priv;
 - Remove unused structure mlxcpld_i2c_regs;
 - Remove from mlxcpld_i2c_priv the next fields:
   retr_num, poll_time, block_sz, xfer_to; use instead macros
   respectively: MLXCPLD_I2C_RETR_NUM, MLXCPLD_I2C_POLL_TIME,
   MLXCPLD_I2C_DATA_REG_SZ, MLXCPLD_I2C_XFER_TO;
 - In mlxcpld_i2c_invalid_len remove unnecessary else;
 - Optimize mlxcpld_i2c_set_transf_data;
 - mlxcpld_i2c_reset - add empty lines after/before mutex
   lock/unlock;
 - mlxcpld_i2c_wait_for_free - cover case timeout is equal
   MLXCPLD_I2C_XFER_TO;
 - mlxcpld_i2c_wait_for_tc:
   - Do not assign err in declaration (also err is removed);
   - Insert empty line before case MLXCPLD_LPCI2C_ACK_IND;
   - inside case MLXCPLD_LPCI2C_ACK_IND - avoid unnecessary
 indentation;
   - Remove case MLXCPLD_LPCI2C_ERR_IND and remove this macro;
 - Add empty lines in mlxcpld_i2c_xfer before/after mutex_lock/
   mutex_unlock;
 - In mlxcpld_i2c_probe add emtpy line after platform_set_drvdata;
 - Replace platfrom handle pdev in mlxcpld_i2c_priv with the pointer
   to the structure device;
 - Place assignment of base_addr near the others;
 - Enclose e-mail with <>;
 Fixes added by Vadim:
 - Change structure description format according to
   Documentation/kernel-documentation.rst guideline;
 - mlxcpld_i2c_wait_for_tc: return error if status reaches default case;
v1->v2
 Fixes added by Vadim:
 - Put new record in Makefile in alphabetic order;
 - Remove http://www.mellanox.com from MAINTAINERS record;
---
 Documentation/i2c/busses/i2c-mlxcpld |  47 +++
 MAINTAINERS  |   8 +
 drivers/i2c/busses/Kconfig   |  11 +
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-mlxcpld.c | 551 +++
 5 files changed, 618 insertions(+)
 create mode 100644 Documentation/i2c/busses/i2c-mlxcpld
 create mode 100644 drivers/i2c/busses/i2c-mlxcpld.c

diff --git a/Documentation/i2c/busses/i2c-mlxcpld 
b/Documentation/i2c/busses/i2c-mlxcpld
new file mode 100644
index 000..0f8678a
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-mlxcpld
@@ -0,0 +1,47 @@
+Driver i2c-mlxcpld
+
+Author: Michael Shych 
+
+This is a for Mellanox I2C controller logic, implemented in Lattice CPLD
+device.
+Device supports:
+ - Master mode.
+ - One physical bus.
+ - Polling mode.
+
+This controller is equipped within the next Mellanox systems:
+"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
+"msn2740", "msn2100".
+
+The next transaction types are supported:
+ - Receive Byte/Block.
+ - Send Byte/Block.
+ - Read Byte/Block.
+ - Write Byte/Block.
+
+Registers:
+CTRL   0x1 - control reg.
+   Resets all the registers.
+HALF_CYC   0x4 - cycle reg.
+   Configure the width of I2C SCL half clock cycle (in 4 
LPC_CLK
+   units).
+I2C_HOLD   0x5 - hold reg.
+   OE (output enable) is delayed by value set to this 
register
+   (in LPC_CLK units)
+CMD0x6 - command reg.
+   Bit 7(lsb), 0 = write, 1 = 

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

[Rajendra Nayak]

On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote:
> On 11/04, Sricharan wrote:
>> Hi,
>>>
>>> A better design would be to check if the associated GDSC is in hw
>>> control mode and then skip the checks because the clocks are no
>>> longer under the control of the registers. I presume we only
>>> enable the clocks here to turn on parent clocks which don't turn
>>> on/off automatically, i.e. the PLL.
>>>
>> I was thinking clocks in the powerdomain still needs to be turned
>> on explicitly, these are branch clocks, irrespective of the PLLs.
>> Putting the gdsc in hw_ctrl, only makes the polling on their status
>> invalid. Anyways would be good to be aligned on this.
> 
> Sure. We also need to make sure the branches are on themselves.
> When the gdsc is disabled the clocks are killed though. This is
> why we can't enable clocks until the gdsc is enabled.
> 
>>
>>> Given that hw control is a static decision I guess that is an
>>> over-engineered solution though? The problem is that this seems
>>> brittle because we have to keep two things in sync, the branches
>>> and the gdsc. So I guess this is ok, but it deserves a comment
>>> like "GDSC is in HW control" so we know what's going on. Also the
>>> commit text could be more explicit that clocks within the gdsc
>>> power domain don't work when the gdsc is off, and with hw control
>>> of a gdsc we can't tell when the gdsc may be off or on.
>>>
>>
>> ok, i will reword the commit log better as above.
>>
>> So i understand its ok to continue with this way of checking ?
>> since we are always having a static association which never changes,
>> than introducing additional fields in the clk_branch which can
>> get the status of the gdsc.
>>
> 
> Well I'm also curious which case is failing. Does turning on the
> clocks work after the gdsc is enabled? Does turning off the
> clocks fail because we don't know when the gdsc has turned off? I
> would hope that the firmware keeps the gdsc on when it's done
> processing things, goes idle, and hands back control to software.
> Right now I'm failing to see how the halt bits fail to toggle
> assuming that firmware isn't misbehaving and the kernel driver is
> power controlling in a coordinated manner with the firmware.

What fails is turning ON the clocks after the gdsc is put under
hardware control (by fails I mean the halt checks fail to indicate
the clock is running, but register accesses etc thereafter suggest
the clocks are actually running)
The halt checks seem to work only while the gdsc is put in SW enabled
state.

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

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

[Rajendra Nayak]

On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote:
> On 11/04, Sricharan wrote:
>> Hi,
>>>
>>> A better design would be to check if the associated GDSC is in hw
>>> control mode and then skip the checks because the clocks are no
>>> longer under the control of the registers. I presume we only
>>> enable the clocks here to turn on parent clocks which don't turn
>>> on/off automatically, i.e. the PLL.
>>>
>> I was thinking clocks in the powerdomain still needs to be turned
>> on explicitly, these are branch clocks, irrespective of the PLLs.
>> Putting the gdsc in hw_ctrl, only makes the polling on their status
>> invalid. Anyways would be good to be aligned on this.
> 
> Sure. We also need to make sure the branches are on themselves.
> When the gdsc is disabled the clocks are killed though. This is
> why we can't enable clocks until the gdsc is enabled.
> 
>>
>>> Given that hw control is a static decision I guess that is an
>>> over-engineered solution though? The problem is that this seems
>>> brittle because we have to keep two things in sync, the branches
>>> and the gdsc. So I guess this is ok, but it deserves a comment
>>> like "GDSC is in HW control" so we know what's going on. Also the
>>> commit text could be more explicit that clocks within the gdsc
>>> power domain don't work when the gdsc is off, and with hw control
>>> of a gdsc we can't tell when the gdsc may be off or on.
>>>
>>
>> ok, i will reword the commit log better as above.
>>
>> So i understand its ok to continue with this way of checking ?
>> since we are always having a static association which never changes,
>> than introducing additional fields in the clk_branch which can
>> get the status of the gdsc.
>>
> 
> Well I'm also curious which case is failing. Does turning on the
> clocks work after the gdsc is enabled? Does turning off the
> clocks fail because we don't know when the gdsc has turned off? I
> would hope that the firmware keeps the gdsc on when it's done
> processing things, goes idle, and hands back control to software.
> Right now I'm failing to see how the halt bits fail to toggle
> assuming that firmware isn't misbehaving and the kernel driver is
> power controlling in a coordinated manner with the firmware.

What fails is turning ON the clocks after the gdsc is put under
hardware control (by fails I mean the halt checks fail to indicate
the clock is running, but register accesses etc thereafter suggest
the clocks are actually running)
The halt checks seem to work only while the gdsc is put in SW enabled
state.

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

Re: [PATCH for-next 01/11] IB/hns: Add the interface for querying QP1

[Anurup M]

On 11/4/2016 10:06 PM, Salil Mehta wrote:
> From: Lijun Ou 
> 
> In old code, It only added the interface for querying non-specific
> QP. This patch mainly adds an interface for querying QP1.
> 
> Signed-off-by: Lijun Ou 
> Reviewed-by: Wei Hu (Xavier) 
> Signed-off-by: Salil Mehta  
> ---
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c |   87 
> +++-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h |6 +-
>  2 files changed, 90 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c 
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> index 71232e5..ca8b784 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> @@ -2630,8 +2630,82 @@ static int hns_roce_v1_query_qpc(struct hns_roce_dev 
> *hr_dev,
>   return ret;
>  }
>  
> -int hns_roce_v1_query_qp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> -  int qp_attr_mask, struct ib_qp_init_attr *qp_init_attr)
> +static int hns_roce_v1_q_sqp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> +  int qp_attr_mask,
> +  struct ib_qp_init_attr *qp_init_attr)
> +{
> + struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device);
> + struct hns_roce_qp *hr_qp = to_hr_qp(ibqp);
> + struct hns_roce_sqp_context *context;
> + u32 addr;
> +
> + context = kzalloc(sizeof(*context), GFP_KERNEL);
> + if (!context)
> + return -ENOMEM;
> +
Do we really need dynamic alloc here as the size is fixed and this memory scope 
is
only inside this function. I think better to use a static allocation.

> + mutex_lock(_qp->mutex);
> +
> + if (hr_qp->state == IB_QPS_RESET) {
I think alloc can be moved after this check (if dynamic alloc is really needed).
> + qp_attr->qp_state = IB_QPS_RESET;
> + goto done;
> + }
> +
> + addr = ROCEE_QP1C_CFG0_0_REG + hr_qp->port * sizeof(*context);
> + context->qp1c_bytes_4 = roce_read(hr_dev, addr);
> + context->sq_rq_bt_l = roce_read(hr_dev, addr + 1);
> + context->qp1c_bytes_12 = roce_read(hr_dev, addr + 2);
> + context->qp1c_bytes_16 = roce_read(hr_dev, addr + 3);
> + context->qp1c_bytes_20 = roce_read(hr_dev, addr + 4);
> + context->cur_rq_wqe_ba_l = roce_read(hr_dev, addr + 5);
> + context->qp1c_bytes_28 = roce_read(hr_dev, addr + 6);
> + context->qp1c_bytes_32 = roce_read(hr_dev, addr + 7);
> + context->cur_sq_wqe_ba_l = roce_read(hr_dev, addr + 8);
> + context->qp1c_bytes_40 = roce_read(hr_dev, addr + 9);
> +
> + hr_qp->state = roce_get_field(context->qp1c_bytes_4,
> +   QP1C_BYTES_4_QP_STATE_M,
> +   QP1C_BYTES_4_QP_STATE_S);
> + qp_attr->qp_state   = hr_qp->state;
> + qp_attr->path_mtu   = IB_MTU_256;
> + qp_attr->path_mig_state = IB_MIG_ARMED;
> + qp_attr->qkey   = QKEY_VAL;
> + qp_attr->rq_psn = 0;
> + qp_attr->sq_psn = 0;
> + qp_attr->dest_qp_num= 1;
> + qp_attr->qp_access_flags = 6;
> +
> + qp_attr->pkey_index = roce_get_field(context->qp1c_bytes_20,
> +  QP1C_BYTES_20_PKEY_IDX_M,
> +  QP1C_BYTES_20_PKEY_IDX_S);
> + qp_attr->port_num = hr_qp->port + 1;
> + qp_attr->sq_draining = 0;
> + qp_attr->max_rd_atomic = 0;
> + qp_attr->max_dest_rd_atomic = 0;
> + qp_attr->min_rnr_timer = 0;
> + qp_attr->timeout = 0;
> + qp_attr->retry_cnt = 0;
> + qp_attr->rnr_retry = 0;
> + qp_attr->alt_timeout = 0;
> +
> +done:
> + qp_attr->cur_qp_state = qp_attr->qp_state;
> + qp_attr->cap.max_recv_wr = hr_qp->rq.wqe_cnt;
> + qp_attr->cap.max_recv_sge = hr_qp->rq.max_gs;
> + qp_attr->cap.max_send_wr = hr_qp->sq.wqe_cnt;
> + qp_attr->cap.max_send_sge = hr_qp->sq.max_gs;
> + qp_attr->cap.max_inline_data = 0;
> + qp_init_attr->cap = qp_attr->cap;
> + qp_init_attr->create_flags = 0;
> +
> + mutex_unlock(_qp->mutex);
> + kfree(context);
> +
> + return 0;
> +}
> +
> +static int hns_roce_v1_q_qp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> + int qp_attr_mask,
> + struct ib_qp_init_attr *qp_init_attr)
>  {
>   struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device);
>   struct hns_roce_qp *hr_qp = to_hr_qp(ibqp);
> @@ -2767,6 +2841,15 @@ int hns_roce_v1_query_qp(struct ib_qp *ibqp, struct 
> ib_qp_attr *qp_attr,
>   return ret;
>  }
>  
> +int hns_roce_v1_query_qp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> +  int qp_attr_mask, struct ib_qp_init_attr *qp_init_attr)
> +{
> + struct hns_roce_qp *hr_qp = to_hr_qp(ibqp);
> +
> + return hr_qp->doorbell_qpn <= 1 ?
> + hns_roce_v1_q_sqp(ibqp, qp_attr, 

Re: [PATCH for-next 01/11] IB/hns: Add the interface for querying QP1

[Anurup M]

On 11/4/2016 10:06 PM, Salil Mehta wrote:
> From: Lijun Ou 
> 
> In old code, It only added the interface for querying non-specific
> QP. This patch mainly adds an interface for querying QP1.
> 
> Signed-off-by: Lijun Ou 
> Reviewed-by: Wei Hu (Xavier) 
> Signed-off-by: Salil Mehta  
> ---
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c |   87 
> +++-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h |6 +-
>  2 files changed, 90 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c 
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> index 71232e5..ca8b784 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> @@ -2630,8 +2630,82 @@ static int hns_roce_v1_query_qpc(struct hns_roce_dev 
> *hr_dev,
>   return ret;
>  }
>  
> -int hns_roce_v1_query_qp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> -  int qp_attr_mask, struct ib_qp_init_attr *qp_init_attr)
> +static int hns_roce_v1_q_sqp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> +  int qp_attr_mask,
> +  struct ib_qp_init_attr *qp_init_attr)
> +{
> + struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device);
> + struct hns_roce_qp *hr_qp = to_hr_qp(ibqp);
> + struct hns_roce_sqp_context *context;
> + u32 addr;
> +
> + context = kzalloc(sizeof(*context), GFP_KERNEL);
> + if (!context)
> + return -ENOMEM;
> +
Do we really need dynamic alloc here as the size is fixed and this memory scope 
is
only inside this function. I think better to use a static allocation.

> + mutex_lock(_qp->mutex);
> +
> + if (hr_qp->state == IB_QPS_RESET) {
I think alloc can be moved after this check (if dynamic alloc is really needed).
> + qp_attr->qp_state = IB_QPS_RESET;
> + goto done;
> + }
> +
> + addr = ROCEE_QP1C_CFG0_0_REG + hr_qp->port * sizeof(*context);
> + context->qp1c_bytes_4 = roce_read(hr_dev, addr);
> + context->sq_rq_bt_l = roce_read(hr_dev, addr + 1);
> + context->qp1c_bytes_12 = roce_read(hr_dev, addr + 2);
> + context->qp1c_bytes_16 = roce_read(hr_dev, addr + 3);
> + context->qp1c_bytes_20 = roce_read(hr_dev, addr + 4);
> + context->cur_rq_wqe_ba_l = roce_read(hr_dev, addr + 5);
> + context->qp1c_bytes_28 = roce_read(hr_dev, addr + 6);
> + context->qp1c_bytes_32 = roce_read(hr_dev, addr + 7);
> + context->cur_sq_wqe_ba_l = roce_read(hr_dev, addr + 8);
> + context->qp1c_bytes_40 = roce_read(hr_dev, addr + 9);
> +
> + hr_qp->state = roce_get_field(context->qp1c_bytes_4,
> +   QP1C_BYTES_4_QP_STATE_M,
> +   QP1C_BYTES_4_QP_STATE_S);
> + qp_attr->qp_state   = hr_qp->state;
> + qp_attr->path_mtu   = IB_MTU_256;
> + qp_attr->path_mig_state = IB_MIG_ARMED;
> + qp_attr->qkey   = QKEY_VAL;
> + qp_attr->rq_psn = 0;
> + qp_attr->sq_psn = 0;
> + qp_attr->dest_qp_num= 1;
> + qp_attr->qp_access_flags = 6;
> +
> + qp_attr->pkey_index = roce_get_field(context->qp1c_bytes_20,
> +  QP1C_BYTES_20_PKEY_IDX_M,
> +  QP1C_BYTES_20_PKEY_IDX_S);
> + qp_attr->port_num = hr_qp->port + 1;
> + qp_attr->sq_draining = 0;
> + qp_attr->max_rd_atomic = 0;
> + qp_attr->max_dest_rd_atomic = 0;
> + qp_attr->min_rnr_timer = 0;
> + qp_attr->timeout = 0;
> + qp_attr->retry_cnt = 0;
> + qp_attr->rnr_retry = 0;
> + qp_attr->alt_timeout = 0;
> +
> +done:
> + qp_attr->cur_qp_state = qp_attr->qp_state;
> + qp_attr->cap.max_recv_wr = hr_qp->rq.wqe_cnt;
> + qp_attr->cap.max_recv_sge = hr_qp->rq.max_gs;
> + qp_attr->cap.max_send_wr = hr_qp->sq.wqe_cnt;
> + qp_attr->cap.max_send_sge = hr_qp->sq.max_gs;
> + qp_attr->cap.max_inline_data = 0;
> + qp_init_attr->cap = qp_attr->cap;
> + qp_init_attr->create_flags = 0;
> +
> + mutex_unlock(_qp->mutex);
> + kfree(context);
> +
> + return 0;
> +}
> +
> +static int hns_roce_v1_q_qp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> + int qp_attr_mask,
> + struct ib_qp_init_attr *qp_init_attr)
>  {
>   struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device);
>   struct hns_roce_qp *hr_qp = to_hr_qp(ibqp);
> @@ -2767,6 +2841,15 @@ int hns_roce_v1_query_qp(struct ib_qp *ibqp, struct 
> ib_qp_attr *qp_attr,
>   return ret;
>  }
>  
> +int hns_roce_v1_query_qp(struct ib_qp *ibqp, struct ib_qp_attr *qp_attr,
> +  int qp_attr_mask, struct ib_qp_init_attr *qp_init_attr)
> +{
> + struct hns_roce_qp *hr_qp = to_hr_qp(ibqp);
> +
> + return hr_qp->doorbell_qpn <= 1 ?
> + hns_roce_v1_q_sqp(ibqp, qp_attr, qp_attr_mask, qp_init_attr) :
> + hns_roce_v1_q_qp(ibqp, qp_attr, qp_attr_mask, 

Re: [PATCH v2 1/2] cpufreq: add new attribute type cpufreq_freq_attr_wr_perm()

[Viresh Kumar]

On 04-11-16, 09:55, Markus Mayer wrote:
> From: Markus Mayer 
> 
> With the new attribute type, it is possible to create write-only
> CPUfreq attributes.
> 
> Signed-off-by: Markus Mayer 
> ---
>  include/linux/cpufreq.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 5fa55fc..ed09930 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -234,6 +234,10 @@ __ATTR(_name, _perm, show_##_name, NULL)
>  static struct freq_attr _name =  \
>  __ATTR(_name, 0644, show_##_name, store_##_name)
>  
> +#define cpufreq_freq_attr_wr_perm(_name, _perm)  \

shouldn't this be _wo_perm ?

Also, I wouldn't mind doing this in the second patch itself.

> +static struct freq_attr _name =  \
> +__ATTR(_name, _perm, NULL, store_##_name)
> +
>  struct global_attr {
>   struct attribute attr;
>   ssize_t (*show)(struct kobject *kobj,
> -- 
> 2.7.4

-- 
viresh

Re: [PATCH v2 1/2] cpufreq: add new attribute type cpufreq_freq_attr_wr_perm()

[Viresh Kumar]

On 04-11-16, 09:55, Markus Mayer wrote:
> From: Markus Mayer 
> 
> With the new attribute type, it is possible to create write-only
> CPUfreq attributes.
> 
> Signed-off-by: Markus Mayer 
> ---
>  include/linux/cpufreq.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 5fa55fc..ed09930 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -234,6 +234,10 @@ __ATTR(_name, _perm, show_##_name, NULL)
>  static struct freq_attr _name =  \
>  __ATTR(_name, 0644, show_##_name, store_##_name)
>  
> +#define cpufreq_freq_attr_wr_perm(_name, _perm)  \

shouldn't this be _wo_perm ?

Also, I wouldn't mind doing this in the second patch itself.

> +static struct freq_attr _name =  \
> +__ATTR(_name, _perm, NULL, store_##_name)
> +
>  struct global_attr {
>   struct attribute attr;
>   ssize_t (*show)(struct kobject *kobj,
> -- 
> 2.7.4

-- 
viresh

linux-next: no release today

[Stephen Rothwell]

Hi all,

There will be no linx-next release today.

-- 
Cheers,
Stephen Rothwell

linux-next: no release today

[Stephen Rothwell]

Hi all,

There will be no linx-next release today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v11 00/22] Add Mediated device support

[Kirti Wankhede]

Verified that this patch series gets applied cleanly to Linux-next upto:
bc33b0ca11e3 Linux 4.9-rc4

Also tested this patch series with above kernel.

Thanks,
Kirti

On 11/7/2016 9:29 AM, Kirti Wankhede wrote:
> 
> 
> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
>> On 05/11/16 08:10, Kirti Wankhede wrote:
>>> This series adds Mediated device support to Linux host kernel. Purpose
>>> of this series is to provide a common interface for mediated device
>>> management that can be used by different devices. This series introduces
>>> Mdev core module that creates and manages mediated devices, VFIO based
>>> driver for mediated devices that are created by mdev core module and
>>> update VFIO type1 IOMMU module to support pinning & unpinning for mediated
>>> devices.
>>>
>>> What changed in v11?
>>> mdev core:
>>>   Register mdev_bus class when first device is registed to avoid panic if
>>>   any vendor driver and mdev driver are selected as built-in but vendor
>>>   driver loads first and then mdev module.
>>> vfio_mdev:
>>>   Added notifier callback function to mdev parent's ops so that notifer
>>>   is registered from vfio_mdev module during device open and unregistered
>>>   it from device close call. This is a optional callback. Some drivers
>>>   using mdev framework might not pin or unpin pages, for example the
>>>   sample mtty driver that simulates serial port. Vendor driver who need to
>>>   pin/unpin pages should provide this callback. Otherwise pin request
>>>   would fail.
>>> vfio_iommu_type1:
>>>   Updated to keep track of who (task and address space) mapped iova range.
>>>   During DMA_UNMAP, same task who mapped it or other task who shares same
>>>   address space is allowed to unmap, otherwise unmap fails.
>>>   QEMU maps few iova ranges initially, then fork threads and from the child
>>>   thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>>   address space, DMA_UNMAP is successful.
>>>   Address space keeps track of pages pinned (pfn_list) by external user /
>>>   mdev devices. This pfn_list is used to verify pfn during unpin_request,
>>>   re-accounting of pages when direct device assigned in hot-unplugged and
>>>   mdev device is present in same container.
>>>   When the container is released, all mapped iova from all tasks are
>>>   unmapped and removed.
>>>
>>>   Tested by assigning below combinations of devices to a single VM:
>>>- GPU pass through only
>>>- vGPU device only
>>>- One GPU pass through and one vGPU device
>>>- Linux VM hot plug and unplug vGPU device while GPU pass through device
>>>  exist
>>>- Linux VM hot plug and unplug GPU pass through device while vGPU device
>>>  exist
>>>
>>>   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
>>>   Resolved against conflicting change:
>>
>> Patch 11/22 does not apply if the patchset is applied on top of 14970f204b19.
>>
>>
> 
> Pull commit 05692d7005a3 (below) commit.
> 
>>
>>>   05692d7005a3 vfio/pci: Fix integer overflows, bitmask check
>>>
> 
> Thanks,
> Kirti
> 
>>>
>>> Kirti Wankhede (22):
>>>   vfio: Mediated device Core driver
>>>   vfio: VFIO based driver for Mediated devices
>>>   vfio: Rearrange functions to get vfio_group from dev
>>>   vfio: Common function to increment container_users
>>>   vfio iommu: Added pin and unpin callback functions to
>>> vfio_iommu_driver_ops
>>>   vfio iommu type1: Update arguments of vfio_lock_acct
>>>   vfio iommu type1: Update argument of vaddr_get_pfn()
>>>   vfio iommu type1: Add find_iommu_group() function
>>>   vfio iommu type1: Add task structure to vfio_dma
>>>   vfio iommu type1: Add support for mediated devices
>>>   vfio iommu: Add blocking notifier to notify DMA_UNMAP
>>>   vfio: Add notifier callback to parent's ops structure of mdev
>>>   vfio: Introduce common function to add capabilities
>>>   vfio_pci: Update vfio_pci to use vfio_info_add_capability()
>>>   vfio: Introduce vfio_set_irqs_validate_and_prepare()
>>>   vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio_platform: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio: Define device_api strings
>>>   docs: Add Documentation for Mediated devices
>>>   docs: Sysfs ABI for mediated device framework
>>>   docs: Sample driver to demonstrate how to use Mediated device
>>> framework.
>>>   MAINTAINERS: Add entry VFIO based Mediated device drivers
>>>
>>>  Documentation/ABI/testing/sysfs-bus-vfio-mdev |  111 ++
>>>  Documentation/vfio-mediated-device.txt|  399 +++
>>>  MAINTAINERS   |9 +
>>>  drivers/vfio/Kconfig  |1 +
>>>  drivers/vfio/Makefile |1 +
>>>  drivers/vfio/mdev/Kconfig |   17 +
>>>  drivers/vfio/mdev/Makefile|5 +
>>>  drivers/vfio/mdev/mdev_core.c |  388 +++
>>>  drivers/vfio/mdev/mdev_driver.c   |  122 ++
>>>  

Re: [PATCH v11 00/22] Add Mediated device support

[Kirti Wankhede]

Verified that this patch series gets applied cleanly to Linux-next upto:
bc33b0ca11e3 Linux 4.9-rc4

Also tested this patch series with above kernel.

Thanks,
Kirti

On 11/7/2016 9:29 AM, Kirti Wankhede wrote:
> 
> 
> On 11/7/2016 9:00 AM, Alexey Kardashevskiy wrote:
>> On 05/11/16 08:10, Kirti Wankhede wrote:
>>> This series adds Mediated device support to Linux host kernel. Purpose
>>> of this series is to provide a common interface for mediated device
>>> management that can be used by different devices. This series introduces
>>> Mdev core module that creates and manages mediated devices, VFIO based
>>> driver for mediated devices that are created by mdev core module and
>>> update VFIO type1 IOMMU module to support pinning & unpinning for mediated
>>> devices.
>>>
>>> What changed in v11?
>>> mdev core:
>>>   Register mdev_bus class when first device is registed to avoid panic if
>>>   any vendor driver and mdev driver are selected as built-in but vendor
>>>   driver loads first and then mdev module.
>>> vfio_mdev:
>>>   Added notifier callback function to mdev parent's ops so that notifer
>>>   is registered from vfio_mdev module during device open and unregistered
>>>   it from device close call. This is a optional callback. Some drivers
>>>   using mdev framework might not pin or unpin pages, for example the
>>>   sample mtty driver that simulates serial port. Vendor driver who need to
>>>   pin/unpin pages should provide this callback. Otherwise pin request
>>>   would fail.
>>> vfio_iommu_type1:
>>>   Updated to keep track of who (task and address space) mapped iova range.
>>>   During DMA_UNMAP, same task who mapped it or other task who shares same
>>>   address space is allowed to unmap, otherwise unmap fails.
>>>   QEMU maps few iova ranges initially, then fork threads and from the child
>>>   thread calls DMA_UNMAP on previously mapped iova. Since child shares same
>>>   address space, DMA_UNMAP is successful.
>>>   Address space keeps track of pages pinned (pfn_list) by external user /
>>>   mdev devices. This pfn_list is used to verify pfn during unpin_request,
>>>   re-accounting of pages when direct device assigned in hot-unplugged and
>>>   mdev device is present in same container.
>>>   When the container is released, all mapped iova from all tasks are
>>>   unmapped and removed.
>>>
>>>   Tested by assigning below combinations of devices to a single VM:
>>>- GPU pass through only
>>>- vGPU device only
>>>- One GPU pass through and one vGPU device
>>>- Linux VM hot plug and unplug vGPU device while GPU pass through device
>>>  exist
>>>- Linux VM hot plug and unplug GPU pass through device while vGPU device
>>>  exist
>>>
>>>   Patch series tested with linux-next upto commit 14970f204b19 @Fri Oct 28
>>>   Resolved against conflicting change:
>>
>> Patch 11/22 does not apply if the patchset is applied on top of 14970f204b19.
>>
>>
> 
> Pull commit 05692d7005a3 (below) commit.
> 
>>
>>>   05692d7005a3 vfio/pci: Fix integer overflows, bitmask check
>>>
> 
> Thanks,
> Kirti
> 
>>>
>>> Kirti Wankhede (22):
>>>   vfio: Mediated device Core driver
>>>   vfio: VFIO based driver for Mediated devices
>>>   vfio: Rearrange functions to get vfio_group from dev
>>>   vfio: Common function to increment container_users
>>>   vfio iommu: Added pin and unpin callback functions to
>>> vfio_iommu_driver_ops
>>>   vfio iommu type1: Update arguments of vfio_lock_acct
>>>   vfio iommu type1: Update argument of vaddr_get_pfn()
>>>   vfio iommu type1: Add find_iommu_group() function
>>>   vfio iommu type1: Add task structure to vfio_dma
>>>   vfio iommu type1: Add support for mediated devices
>>>   vfio iommu: Add blocking notifier to notify DMA_UNMAP
>>>   vfio: Add notifier callback to parent's ops structure of mdev
>>>   vfio: Introduce common function to add capabilities
>>>   vfio_pci: Update vfio_pci to use vfio_info_add_capability()
>>>   vfio: Introduce vfio_set_irqs_validate_and_prepare()
>>>   vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio_platform: Updated to use vfio_set_irqs_validate_and_prepare()
>>>   vfio: Define device_api strings
>>>   docs: Add Documentation for Mediated devices
>>>   docs: Sysfs ABI for mediated device framework
>>>   docs: Sample driver to demonstrate how to use Mediated device
>>> framework.
>>>   MAINTAINERS: Add entry VFIO based Mediated device drivers
>>>
>>>  Documentation/ABI/testing/sysfs-bus-vfio-mdev |  111 ++
>>>  Documentation/vfio-mediated-device.txt|  399 +++
>>>  MAINTAINERS   |9 +
>>>  drivers/vfio/Kconfig  |1 +
>>>  drivers/vfio/Makefile |1 +
>>>  drivers/vfio/mdev/Kconfig |   17 +
>>>  drivers/vfio/mdev/Makefile|5 +
>>>  drivers/vfio/mdev/mdev_core.c |  388 +++
>>>  drivers/vfio/mdev/mdev_driver.c   |  122 ++
>>>  

Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free

[Anshuman Khandual]

On 11/07/2016 07:18 AM, Xishi Qiu wrote:
> On 2016/11/5 20:29, Anshuman Khandual wrote:
> 
>> On 11/05/2016 01:27 PM, Xishi Qiu wrote:
>>> Usually the memory of android phones is very small, so after a long
>>> running, the fragment is very large. Kernel stack which called by
>>> alloc_thread_stack_node() usually alloc 16K memory, and it failed
>>> frequently.
>>>
>>> However we have CONFIG_VMAP_STACK now, but it do not support arm64,
>>> and maybe it has some regression because of vmalloc, it need to
>>> find an area and create page table dynamically, this will take a short
>>> time.
>>>
>>> I think we can merge as soon as possible when pcp alloc/free to reduce
>>> fragment. The pcp page is hot page, so free it will cause cache miss,
>>> I use perf to test it, but it seems the regression is not so much, maybe
>>> it need to test more. Any reply is welcome.
>>
>> The idea of PCP is to have a fast allocation mechanism which does not depend
>> on an interrupt safe spin lock for every allocation. I am not very familiar
>> with this part of code but the following documentation from Mel Gorman kind
>> of explains that the this type of fragmentation problem which you might be
>> observing as one of the limitations of PCP mechanism.
>>
>> https://www.kernel.org/doc/gorman/html/understand/understand009.html
>> "Per CPU page list" sub header.
>>
> 
> "The last potential problem is that buddies of newly freed pages could exist
> in other pagesets leading to possible fragmentation problems."
> So we should not change it, and this is a known issue, right?

Seems like that.

Re: [RFC][PATCH] mm: merge as soon as possible when pcp alloc/free

[Anshuman Khandual]

On 11/07/2016 07:18 AM, Xishi Qiu wrote:
> On 2016/11/5 20:29, Anshuman Khandual wrote:
> 
>> On 11/05/2016 01:27 PM, Xishi Qiu wrote:
>>> Usually the memory of android phones is very small, so after a long
>>> running, the fragment is very large. Kernel stack which called by
>>> alloc_thread_stack_node() usually alloc 16K memory, and it failed
>>> frequently.
>>>
>>> However we have CONFIG_VMAP_STACK now, but it do not support arm64,
>>> and maybe it has some regression because of vmalloc, it need to
>>> find an area and create page table dynamically, this will take a short
>>> time.
>>>
>>> I think we can merge as soon as possible when pcp alloc/free to reduce
>>> fragment. The pcp page is hot page, so free it will cause cache miss,
>>> I use perf to test it, but it seems the regression is not so much, maybe
>>> it need to test more. Any reply is welcome.
>>
>> The idea of PCP is to have a fast allocation mechanism which does not depend
>> on an interrupt safe spin lock for every allocation. I am not very familiar
>> with this part of code but the following documentation from Mel Gorman kind
>> of explains that the this type of fragmentation problem which you might be
>> observing as one of the limitations of PCP mechanism.
>>
>> https://www.kernel.org/doc/gorman/html/understand/understand009.html
>> "Per CPU page list" sub header.
>>
> 
> "The last potential problem is that buddies of newly freed pages could exist
> in other pagesets leading to possible fragmentation problems."
> So we should not change it, and this is a known issue, right?

Seems like that.

Re: [PATCH v2 2/2] cpufreq: stats: clear statistics

[Viresh Kumar]

On 04-11-16, 09:55, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Allow CPUfreq statistics to be cleared by writing anything to
> /sys/.../cpufreq/stats/reset.
> 
> Signed-off-by: Markus Mayer 
> ---
>  Documentation/cpu-freq/cpufreq-stats.txt |  6 ++
>  drivers/cpufreq/cpufreq_stats.c  | 22 ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/cpu-freq/cpufreq-stats.txt 
> b/Documentation/cpu-freq/cpufreq-stats.txt
> index 8d9773f..3c355f6 100644
> --- a/Documentation/cpu-freq/cpufreq-stats.txt
> +++ b/Documentation/cpu-freq/cpufreq-stats.txt
> @@ -44,11 +44,17 @@ the stats driver insertion.
>  total 0
>  drwxr-xr-x  2 root root0 May 14 16:06 .
>  drwxr-xr-x  3 root root0 May 14 15:58 ..
> +--w---  1 root root 4096 May 14 16:06 reset
>  -r--r--r--  1 root root 4096 May 14 16:06 time_in_state
>  -r--r--r--  1 root root 4096 May 14 16:06 total_trans
>  -r--r--r--  1 root root 4096 May 14 16:06 trans_table
>  
> 
>  
> +-  reset
> +Write-only attribute that can be used to reset the stat counters. This can be
> +useful for evaluating system behaviour under different governors without the
> +need for a reboot.
> +
>  -  time_in_state
>  This gives the amount of time spent in each of the frequencies supported by
>  this CPU. The cat output will have " " pair in each line, 
> which
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index 06d3abd..66419e6 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -41,6 +41,18 @@ static int cpufreq_stats_update(struct cpufreq_stats 
> *stats)
>   return 0;
>  }
>  
> +static void cpufreq_stats_clear_table(struct cpufreq_stats *stats)
> +{
> + unsigned int count = stats->max_state;
> +
> + memset(stats->time_in_state, 0, count * sizeof(u64));
> +#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
> + memset(stats->trans_table, 0, count * count * sizeof(int));
> +#endif
> + stats->last_time = get_jiffies_64();
> + stats->total_trans = 0;
> +}
> +
>  static ssize_t show_total_trans(struct cpufreq_policy *policy, char *buf)
>  {
>   return sprintf(buf, "%d\n", policy->stats->total_trans);
> @@ -64,6 +76,14 @@ static ssize_t show_time_in_state(struct cpufreq_policy 
> *policy, char *buf)
>   return len;
>  }
>  
> +static ssize_t store_reset(struct cpufreq_policy *policy, const char *buf,
> +size_t count)
> +{
> + /* We don't care what is written to the attribute. */
> + cpufreq_stats_clear_table(policy->stats);
> + return count;
> +}
> +
>  #ifdef CONFIG_CPU_FREQ_STAT_DETAILS
>  static ssize_t show_trans_table(struct cpufreq_policy *policy, char *buf)
>  {
> @@ -113,10 +133,12 @@ cpufreq_freq_attr_ro(trans_table);
>  
>  cpufreq_freq_attr_ro(total_trans);
>  cpufreq_freq_attr_ro(time_in_state);
> +cpufreq_freq_attr_wr_perm(reset, 0200);

Just drop the perm argument and this patch looks fine as well.

-- 
viresh

Re: [PATCH v2 2/2] cpufreq: stats: clear statistics

[Viresh Kumar]

On 04-11-16, 09:55, Markus Mayer wrote:
> From: Markus Mayer 
> 
> Allow CPUfreq statistics to be cleared by writing anything to
> /sys/.../cpufreq/stats/reset.
> 
> Signed-off-by: Markus Mayer 
> ---
>  Documentation/cpu-freq/cpufreq-stats.txt |  6 ++
>  drivers/cpufreq/cpufreq_stats.c  | 22 ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/cpu-freq/cpufreq-stats.txt 
> b/Documentation/cpu-freq/cpufreq-stats.txt
> index 8d9773f..3c355f6 100644
> --- a/Documentation/cpu-freq/cpufreq-stats.txt
> +++ b/Documentation/cpu-freq/cpufreq-stats.txt
> @@ -44,11 +44,17 @@ the stats driver insertion.
>  total 0
>  drwxr-xr-x  2 root root0 May 14 16:06 .
>  drwxr-xr-x  3 root root0 May 14 15:58 ..
> +--w---  1 root root 4096 May 14 16:06 reset
>  -r--r--r--  1 root root 4096 May 14 16:06 time_in_state
>  -r--r--r--  1 root root 4096 May 14 16:06 total_trans
>  -r--r--r--  1 root root 4096 May 14 16:06 trans_table
>  
> 
>  
> +-  reset
> +Write-only attribute that can be used to reset the stat counters. This can be
> +useful for evaluating system behaviour under different governors without the
> +need for a reboot.
> +
>  -  time_in_state
>  This gives the amount of time spent in each of the frequencies supported by
>  this CPU. The cat output will have " " pair in each line, 
> which
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index 06d3abd..66419e6 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -41,6 +41,18 @@ static int cpufreq_stats_update(struct cpufreq_stats 
> *stats)
>   return 0;
>  }
>  
> +static void cpufreq_stats_clear_table(struct cpufreq_stats *stats)
> +{
> + unsigned int count = stats->max_state;
> +
> + memset(stats->time_in_state, 0, count * sizeof(u64));
> +#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
> + memset(stats->trans_table, 0, count * count * sizeof(int));
> +#endif
> + stats->last_time = get_jiffies_64();
> + stats->total_trans = 0;
> +}
> +
>  static ssize_t show_total_trans(struct cpufreq_policy *policy, char *buf)
>  {
>   return sprintf(buf, "%d\n", policy->stats->total_trans);
> @@ -64,6 +76,14 @@ static ssize_t show_time_in_state(struct cpufreq_policy 
> *policy, char *buf)
>   return len;
>  }
>  
> +static ssize_t store_reset(struct cpufreq_policy *policy, const char *buf,
> +size_t count)
> +{
> + /* We don't care what is written to the attribute. */
> + cpufreq_stats_clear_table(policy->stats);
> + return count;
> +}
> +
>  #ifdef CONFIG_CPU_FREQ_STAT_DETAILS
>  static ssize_t show_trans_table(struct cpufreq_policy *policy, char *buf)
>  {
> @@ -113,10 +133,12 @@ cpufreq_freq_attr_ro(trans_table);
>  
>  cpufreq_freq_attr_ro(total_trans);
>  cpufreq_freq_attr_ro(time_in_state);
> +cpufreq_freq_attr_wr_perm(reset, 0200);

Just drop the perm argument and this patch looks fine as well.

-- 
viresh

Re: [PATCH v2 1/2] cpufreq: add new attribute type cpufreq_freq_attr_wr_perm()

[Viresh Kumar]

On 07-11-16, 10:03, Viresh Kumar wrote:
> On 04-11-16, 09:55, Markus Mayer wrote:
> > From: Markus Mayer 
> > 
> > With the new attribute type, it is possible to create write-only
> > CPUfreq attributes.
> > 
> > Signed-off-by: Markus Mayer 
> > ---
> >  include/linux/cpufreq.h | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index 5fa55fc..ed09930 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -234,6 +234,10 @@ __ATTR(_name, _perm, show_##_name, NULL)
> >  static struct freq_attr _name =\
> >  __ATTR(_name, 0644, show_##_name, store_##_name)
> >  
> > +#define cpufreq_freq_attr_wr_perm(_name, _perm)\
> 
> shouldn't this be _wo_perm ?
> 
> Also, I wouldn't mind doing this in the second patch itself.

Also there is no need to define a _perm variant here, and then you can avoid
sending 0200 as argument as well.

-- 
viresh

Re: [PATCH v7 2/2] x86/apic: x2apic write eoi msr notrace

[Wanpeng Li]

2016-11-03 5:10 GMT+08:00 Borislav Petkov :
> On Mon, Oct 31, 2016 at 09:37:02AM +0800, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> | RCU used illegally from idle CPU!
>> | rcu_scheduler_active = 1, debug_locks = 0
>> | RCU used illegally from extended quiescent state!
>> | no locks held by swapper/1/0.
>> |
>> |  [] do_trace_write_msr+0x135/0x140
>> |  [] native_write_msr+0x20/0x30
>> |  [] native_apic_msr_eoi_write+0x1d/0x30
>> |  [] smp_reschedule_interrupt+0x1d/0x30
>> |  [] reschedule_interrupt+0x96/0xa0
>
> Please remove the text between [] and the offsets after "+..." - those
> are useless in a commit message.
>
>> Reschedule interrupt may be called in cpu idle state. This causes lockdep
>
> s/cpu/CPU/
>
>> check warning above.
>>
>> As Peterz pointed out:
>>
>> | So now we're making a very frequent interrupt slower because of debug
>> | code.
>> |
>> | The thing is, many many smp_reschedule_interrupt() invocations don't
>> | actually execute anything much at all and are only send to tickle the
>
> s/send/sent/

I will send a new version to clean it up.

Regards,
Wanpeng Li

Re: [PATCH v2 1/2] cpufreq: add new attribute type cpufreq_freq_attr_wr_perm()

[Viresh Kumar]

On 07-11-16, 10:03, Viresh Kumar wrote:
> On 04-11-16, 09:55, Markus Mayer wrote:
> > From: Markus Mayer 
> > 
> > With the new attribute type, it is possible to create write-only
> > CPUfreq attributes.
> > 
> > Signed-off-by: Markus Mayer 
> > ---
> >  include/linux/cpufreq.h | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> > index 5fa55fc..ed09930 100644
> > --- a/include/linux/cpufreq.h
> > +++ b/include/linux/cpufreq.h
> > @@ -234,6 +234,10 @@ __ATTR(_name, _perm, show_##_name, NULL)
> >  static struct freq_attr _name =\
> >  __ATTR(_name, 0644, show_##_name, store_##_name)
> >  
> > +#define cpufreq_freq_attr_wr_perm(_name, _perm)\
> 
> shouldn't this be _wo_perm ?
> 
> Also, I wouldn't mind doing this in the second patch itself.

Also there is no need to define a _perm variant here, and then you can avoid
sending 0200 as argument as well.

-- 
viresh

Re: [PATCH v7 2/2] x86/apic: x2apic write eoi msr notrace

[Wanpeng Li]

2016-11-03 5:10 GMT+08:00 Borislav Petkov :
> On Mon, Oct 31, 2016 at 09:37:02AM +0800, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> | RCU used illegally from idle CPU!
>> | rcu_scheduler_active = 1, debug_locks = 0
>> | RCU used illegally from extended quiescent state!
>> | no locks held by swapper/1/0.
>> |
>> |  [] do_trace_write_msr+0x135/0x140
>> |  [] native_write_msr+0x20/0x30
>> |  [] native_apic_msr_eoi_write+0x1d/0x30
>> |  [] smp_reschedule_interrupt+0x1d/0x30
>> |  [] reschedule_interrupt+0x96/0xa0
>
> Please remove the text between [] and the offsets after "+..." - those
> are useless in a commit message.
>
>> Reschedule interrupt may be called in cpu idle state. This causes lockdep
>
> s/cpu/CPU/
>
>> check warning above.
>>
>> As Peterz pointed out:
>>
>> | So now we're making a very frequent interrupt slower because of debug
>> | code.
>> |
>> | The thing is, many many smp_reschedule_interrupt() invocations don't
>> | actually execute anything much at all and are only send to tickle the
>
> s/send/sent/

I will send a new version to clean it up.

Regards,
Wanpeng Li