* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits
The patch titled
Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree. Its filename was
coredump-fix-unfreezable-coredumping-task.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task
It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.
Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation. So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.
Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.
Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/coredump.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
#include <linux/slab.h>
#include <linux/file.h>
#include <linux/fdtable.h>
+#include <linux/freezer.h>
#include <linux/mm.h>
#include <linux/stat.h>
#include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
if (core_waiters > 0) {
struct core_thread *ptr;
+ freezer_do_not_count();
wait_for_completion(&core_state->startup);
+ freezer_count();
/*
* Wait for all the threads to become inactive, so that
* all the thread context (extended register state, like
_
Patches currently in -mm which might be from aryabinin@virtuozzo.com are
^ permalink raw reply
* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits
The patch titled
Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree. Its filename was
coredump-fix-unfreezable-coredumping-task.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task
It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.
Inability to freeze a task during suspend will cause suspend to fail.
Also CRIU uses cgroup freezer during dump operation. So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.
Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.
Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/coredump.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
#include <linux/slab.h>
#include <linux/file.h>
#include <linux/fdtable.h>
+#include <linux/freezer.h>
#include <linux/mm.h>
#include <linux/stat.h>
#include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
if (core_waiters > 0) {
struct core_thread *ptr;
+ freezer_do_not_count();
wait_for_completion(&core_state->startup);
+ freezer_count();
/*
* Wait for all the threads to become inactive, so that
* all the thread context (extended register state, like
_
Patches currently in -mm which might be from aryabinin@virtuozzo.com are
^ permalink raw reply
* [merged] memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: gthelen, cl, hannes, iamjoonsoo.kim, mhocko, penberg, rientjes,
thgarnie, vdavydov.dev, mm-commits
The patch titled
Subject: memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
has been removed from the -mm tree. Its filename was
memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Greg Thelen <gthelen@google.com>
Subject: memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
While testing OBJFREELIST_SLAB integration with pagealloc, we found a bug
where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB &
CFLGS_OBJFREELIST_SLAB. When it happened, critical allocations needed for
loading drivers or creating new caches will fail.
The original kmem_cache is created early making OFF_SLAB not possible.
When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc is
enabled it will try to enable it first under certain conditions. Given
kmem_cache(sys) reuses the original flag, you can have both flags at the
same time resulting in allocation failures and odd behaviors.
This fix discards allocator specific flags from memcg before calling
create_cache.
The bug exists since 4.6-rc1 and affects testing debug pagealloc
configurations.
Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB")
Link: http://lkml.kernel.org/r/1478553075-120242-1-git-send-email-thgarnie@google.com
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Thomas Garnier <thgarnie@google.com>
Tested-by: Thomas Garnier <thgarnie@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/slab_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN mm/slab_common.c~memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab mm/slab_common.c
--- a/mm/slab_common.c~memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab
+++ a/mm/slab_common.c
@@ -533,8 +533,8 @@ void memcg_create_kmem_cache(struct mem_
s = create_cache(cache_name, root_cache->object_size,
root_cache->size, root_cache->align,
- root_cache->flags, root_cache->ctor,
- memcg, root_cache);
+ root_cache->flags & CACHE_CREATE_MASK,
+ root_cache->ctor, memcg, root_cache);
/*
* If we could not create a memcg cache, do not complain, because
* that's not critical at all as we can always proceed with the root
_
Patches currently in -mm which might be from gthelen@google.com are
mm-slab-faster-active-and-free-stats.patch
^ permalink raw reply
* [merged] mm-kmemleak-scan-dataro_after_init.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: jakub.kicinski, arnd, catalin.marinas, heiko.carstens, johannes,
schwidefsky, xiyou.wangcong, mm-commits
The patch titled
Subject: mm: kmemleak: scan .data.ro_after_init
has been removed from the -mm tree. Its filename was
mm-kmemleak-scan-dataro_after_init.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: mm: kmemleak: scan .data.ro_after_init
Limit the number of kmemleak false positives by including
.data.ro_after_init in memory scanning. To achieve this we need to add
symbols for start and end of the section to the linker scripts.
The problem was been uncovered by commit 56989f6d8568 ("genetlink: mark
families as __ro_after_init").
Link: http://lkml.kernel.org/r/1478274173-15218-1-git-send-email-jakub.kicinski@netronome.com
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/s390/kernel/vmlinux.lds.S | 2 ++
include/asm-generic/sections.h | 3 +++
include/asm-generic/vmlinux.lds.h | 5 ++++-
mm/kmemleak.c | 1 +
4 files changed, 10 insertions(+), 1 deletion(-)
diff -puN arch/s390/kernel/vmlinux.lds.S~mm-kmemleak-scan-dataro_after_init arch/s390/kernel/vmlinux.lds.S
--- a/arch/s390/kernel/vmlinux.lds.S~mm-kmemleak-scan-dataro_after_init
+++ a/arch/s390/kernel/vmlinux.lds.S
@@ -62,9 +62,11 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__start_ro_after_init = .;
+ __start_data_ro_after_init = .;
.data..ro_after_init : {
*(.data..ro_after_init)
}
+ __end_data_ro_after_init = .;
EXCEPTION_TABLE(16)
. = ALIGN(PAGE_SIZE);
__end_ro_after_init = .;
diff -puN include/asm-generic/sections.h~mm-kmemleak-scan-dataro_after_init include/asm-generic/sections.h
--- a/include/asm-generic/sections.h~mm-kmemleak-scan-dataro_after_init
+++ a/include/asm-generic/sections.h
@@ -14,6 +14,8 @@
* [_sdata, _edata]: contains .data.* sections, may also contain .rodata.*
* and/or .init.* sections.
* [__start_rodata, __end_rodata]: contains .rodata.* sections
+ * [__start_data_ro_after_init, __end_data_ro_after_init]:
+ * contains data.ro_after_init section
* [__init_begin, __init_end]: contains .init.* sections, but .init.text.*
* may be out of this range on some architectures.
* [_sinittext, _einittext]: contains .init.text.* sections
@@ -31,6 +33,7 @@ extern char _data[], _sdata[], _edata[];
extern char __bss_start[], __bss_stop[];
extern char __init_begin[], __init_end[];
extern char _sinittext[], _einittext[];
+extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
extern char _end[];
extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
extern char __kprobes_text_start[], __kprobes_text_end[];
diff -puN include/asm-generic/vmlinux.lds.h~mm-kmemleak-scan-dataro_after_init include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h~mm-kmemleak-scan-dataro_after_init
+++ a/include/asm-generic/vmlinux.lds.h
@@ -259,7 +259,10 @@
* own by defining an empty RO_AFTER_INIT_DATA.
*/
#ifndef RO_AFTER_INIT_DATA
-#define RO_AFTER_INIT_DATA *(.data..ro_after_init)
+#define RO_AFTER_INIT_DATA \
+ __start_data_ro_after_init = .; \
+ *(.data..ro_after_init) \
+ __end_data_ro_after_init = .;
#endif
/*
diff -puN mm/kmemleak.c~mm-kmemleak-scan-dataro_after_init mm/kmemleak.c
--- a/mm/kmemleak.c~mm-kmemleak-scan-dataro_after_init
+++ a/mm/kmemleak.c
@@ -1414,6 +1414,7 @@ static void kmemleak_scan(void)
/* data/bss scanning */
scan_large_block(_sdata, _edata);
scan_large_block(__bss_start, __bss_stop);
+ scan_large_block(__start_data_ro_after_init, __end_data_ro_after_init);
#ifdef CONFIG_SMP
/* per-cpu sections scanning */
_
Patches currently in -mm which might be from jakub.kicinski@netronome.com are
^ permalink raw reply
* [merged] lib-stackdepot-export-save-fetch-stack-for-drivers.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
To: chris, aryabinin, daniel.vetter, dvyukov, glider, iamjoonsoo.kim,
kirill, mm-commits
The patch titled
Subject: lib/stackdepot: export save/fetch stack for drivers
has been removed from the -mm tree. Its filename was
lib-stackdepot-export-save-fetch-stack-for-drivers.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: lib/stackdepot: export save/fetch stack for drivers
Some drivers would like to record stacktraces in order to aide leak
tracing. As stackdepot already provides a facility for only storing the
unique traces, thereby reducing the memory required, export that
functionality for use by drivers.
The code was originally created for KASAN and moved under lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot
for SLAB") so that it could be shared with mm/. In turn, we want to share
it now with drivers.
Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
lib/stackdepot.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers lib/stackdepot.c
--- a/lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers
+++ a/lib/stackdepot.c
@@ -192,6 +192,7 @@ void depot_fetch_stack(depot_stack_handl
trace->entries = stack->entries;
trace->skip = 0;
}
+EXPORT_SYMBOL_GPL(depot_fetch_stack);
/**
* depot_save_stack - save stack in a stack depot.
@@ -283,3 +284,4 @@ exit:
fast_exit:
return retval;
}
+EXPORT_SYMBOL_GPL(depot_save_stack);
_
Patches currently in -mm which might be from chris@chris-wilson.co.uk are
^ permalink raw reply
* Re: [PATCH 2/2] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Stephen Boyd @ 2016-11-14 20:03 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, robh+dt, mark.rutland, linux-kernel, linux-clk,
devicetree, bin.chen, elder, hermit.wangheming, yanhaifeng,
wenpan, howell.yang
In-Reply-To: <0c3b49a4-f58c-253a-fd87-ab52b0b26010@hisilicon.com>
On 11/14, Jiancheng Xue wrote:
> Hi Stephen,
>
> On 2016/11/12 8:04, Stephen Boyd wrote:
> > On 10/29, Jiancheng Xue wrote:
> >
> > Should be a From: Pan Wen here?
> >
> >> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
> >> Generator) module generates clock and reset signals used
> >> by other module blocks on SoC.
> >>
> >> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> >
> > And you should have signed it off? Care to resend or state that
> > this is incorrectly attributed to you instead of Pan Wen?
> >
>
> Pan Wen is the main author of this patch. I just made some small modification
> with agreement from him. Do I need to resend this patch if it's better to add my
> signed-off?
>
Sure I'll apply the resent one. But you should also make sure to
retain Pan Wen's authorship. I'll go do that when applying it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Paulo Zanoni @ 2016-11-14 20:03 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx, stable
In-Reply-To: <20161109013809.GG6536@intel.com>
Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> >
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> >
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: stable@vger.kernel.org
> > Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> This seems to match my reading of the spec update from Nov 4th, so:
>
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Patch merged today. Thanks for the review!
>
>
> >
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > y_min_scanlines = 4;
> > }
> >
> > + if (apply_memory_bw_wa)
> > + y_min_scanlines *= 2;
> > +
> > plane_bytes_per_line = width * cpp;
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > plane_blocks_per_line);
> >
> > y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > - if (apply_memory_bw_wa)
> > - y_tile_minimum *= 2;
> >
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Paulo Zanoni @ 2016-11-14 20:03 UTC (permalink / raw)
To: Matt Roper; +Cc: intel-gfx, stable
In-Reply-To: <20161109013809.GG6536@intel.com>
Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> >
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> >
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: stable@vger.kernel.org
> > Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> This seems to match my reading of the spec update from Nov 4th, so:
>
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Patch merged today. Thanks for the review!
>
>
> >
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > y_min_scanlines = 4;
> > }
> >
> > + if (apply_memory_bw_wa)
> > + y_min_scanlines *= 2;
> > +
> > plane_bytes_per_line = width * cpp;
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > plane_blocks_per_line);
> >
> > y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > - if (apply_memory_bw_wa)
> > - y_tile_minimum *= 2;
> >
> > if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Geert Uytterhoeven @ 2016-11-14 20:04 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, Ramesh Shanmugasundaram, Mark Rutland,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20161114195200.s62ga2bnutsrocyf@rob-hp-laptop>
Hi Rob,
On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@
>> > +Example
>> > +--------
>> > +
>> > +SoC common dtsi file
>> > +
>> > + drif00: rif@e6f40000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f40000 0 0x64>;
>> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 515>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > + dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.
The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif01: rif@e6f50000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f50000 0 0x64>;
>> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 514>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > + dma-names = "rx", "rx";
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif0: rif@0 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + sub-channels = <&drif00>, <&drif01>;
>> > + status = "disabled";
>> > + };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two channels
>> are mostly independent having separate DT nodes makes sense to me. However, as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.
Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Geert Uytterhoeven @ 2016-11-14 20:04 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, Ramesh Shanmugasundaram, Mark Rutland,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161114195200.s62ga2bnutsrocyf@rob-hp-laptop>
Hi Rob,
On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@
>> > +Example
>> > +--------
>> > +
>> > +SoC common dtsi file
>> > +
>> > + drif00: rif@e6f40000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f40000 0 0x64>;
>> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 515>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > + dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.
The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif01: rif@e6f50000 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f50000 0 0x64>;
>> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> > + clocks = <&cpg CPG_MOD 514>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > + dma-names = "rx", "rx";
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif0: rif@0 {
>> > + compatible = "renesas,r8a7795-drif",
>> > + "renesas,rcar-gen3-drif";
>> > + sub-channels = <&drif00>, <&drif01>;
>> > + status = "disabled";
>> > + };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two channels
>> are mostly independent having separate DT nodes makes sense to me. However, as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.
Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] block: fast-path for small and simple direct I/O requests
From: Jens Axboe @ 2016-11-14 20:00 UTC (permalink / raw)
To: Omar Sandoval; +Cc: axboe, linux-block, linux-fsdevel, hch, Christoph Hellwig
In-Reply-To: <20161114193339.GA31821@vader.DHCP.thefacebook.com>
On 11/14/2016 12:33 PM, Omar Sandoval wrote:
> On Fri, Nov 11, 2016 at 10:11:25PM -0700, Jens Axboe wrote:
>> From: Christoph Hellwig <hch@lst.de>
>>
>> This patch adds a small and simple fast patch for small direct I/O
>> requests on block devices that don't use AIO. Between the neat
>> bio_iov_iter_get_pages helper that avoids allocating a page array
>> for get_user_pages and the on-stack bio and biovec this avoid memory
>> allocations and atomic operations entirely in the direct I/O code
>> (lower levels might still do memory allocations and will usually
>> have at least some atomic operations, though).
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Jens Axboe <axboe@fb.com>
>> ---
>> fs/block_dev.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 80 insertions(+)
>>
>
> [snip]
>
>> static ssize_t
>> blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>> {
>> struct file *file = iocb->ki_filp;
>> struct inode *inode = bdev_file_inode(file);
>> + int nr_pages;
>>
>> + nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
>> + if (!nr_pages)
>> + return 0;
>> + if (is_sync_kiocb(iocb) && nr_pages <= DIO_INLINE_BIO_VECS)
>> + return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
>> return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
>> blkdev_get_block, NULL, NULL,
>> DIO_SKIP_DIO_COUNT);
>
> __blockdev_direct_IO() does a few cache prefetches that we're now
> bypassing, do we want to do the same in __blkdev_direct_IO_simple()?
> That's the stuff added in 65dd2aa90aa1 ("dio: optimize cache misses in
> the submission path").
Prefetches like that tend to grow stale, in my experience. So we should
probably just evaluate the new path cache behavior and see if it makes
sense.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] Handle SForced in storage_modifiers
From: Luc Van Oostenryck @ 2016-11-14 20:04 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-sparse, Al Viro
In-Reply-To: <1479150736-28392-1-git-send-email-jlayton@redhat.com>
On Mon, Nov 14, 2016 at 02:12:16PM -0500, Jeff Layton wrote:
> We have been seeing errors like this for a while now in the sparse
> Fedora package, when doing kernel builds:
>
> ./include/linux/err.h:53:25: warning: dereference of noderef expression
> ./include/linux/err.h:35:16: warning: dereference of noderef expression
>
> This spews all over the build because this comes from IS_ERR(), which
> is called everywhere. Even odder, it turns out that if we build the
> package with -fpic turned off, then it works fine.
>
> With some brute-force debugging, I think I've finally found the cause.
> This array is missing the SForced element. When this is added then the
> problem goes away.
>
> As to why this goes away when -fpic is removed, I can only assume that
> we get lucky with the memory layout and have a zeroed out region just
> beyond the end of the array.
>
> Fixes: 3829c4d8b097776e6b3472290a9fae08a705ab7a
> Cc: Al Viro <viro@ftp.linux.org.uk>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> parse.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/parse.c b/parse.c
> index 205e12644a6c..b290ff2636f2 100644
> --- a/parse.c
> +++ b/parse.c
> @@ -1286,7 +1286,8 @@ static unsigned long storage_modifiers(struct decl_state *ctx)
> [SAuto] = MOD_AUTO,
> [SExtern] = MOD_EXTERN,
> [SStatic] = MOD_STATIC,
> - [SRegister] = MOD_REGISTER
> + [SRegister] = MOD_REGISTER,
> + [SForced] = 0
> };
> return mod[ctx->storage_class] | (ctx->is_inline ? MOD_INLINE : 0)
> | (ctx->is_tls ? MOD_TLS : 0);
> --
Humm,
The array is statically initialized and never modified,
your patch shouldn't change anything, and this regardless of
the memory layout or compiler options.
Luc Van Oostenryck
^ permalink raw reply
* Re: [PATCH 0/7] FBC atomic cleanups
From: Paulo Zanoni @ 2016-11-14 20:04 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1478883461-20201-1-git-send-email-paulo.r.zanoni@intel.com>
Em Sex, 2016-11-11 às 14:57 -0200, Paulo Zanoni escreveu:
> Ville pointed out two ugly defects in the FBC code, and while trying
> to fix them I spotted a few extra things. No real-world bugs fixed
> here, but IMHO the code is much easier to read now.
I merged patches 1-5 and 7, and will resend patch 6 as a separate
series. Thanks for the quick reviews!
>
> Paulo Zanoni (7):
> drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop
> drm/i915/fbc: replace a loop with
> drm_atomic_get_existing_crtc_state()
> drm/i915/fbc: extract intel_fbc_can_enable()
> drm/i915/fbc: inline intel_fbc_can_choose()
> drm/i915/fbc: use drm_atomic_get_existing_crtc_state when
> appropriate
> drm/i915/fbc: move from crtc_state->enable_fbc to
> plane_state->enable_fbc
> drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()
>
> drivers/gpu/drm/i915/intel_drv.h | 4 +-
> drivers/gpu/drm/i915/intel_fbc.c | 97 ++++++++++++++++++----------
> ------------
> 2 files changed, 46 insertions(+), 55 deletions(-)
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
From: Konrad Rzeszutek Wilk @ 2016-11-14 20:05 UTC (permalink / raw)
To: xen-devel, boris.ostrovsky
Cc: andrew.cooper3, wei.liu2, klancaster, jbeulich, lars.kurth
In-Reply-To: <1474571626-6694-5-git-send-email-boris.ostrovsky@oracle.com>
On Sat, Nov 12, 2016 at 01:02:08PM +0000, Ken Lancaster wrote:
> My apologies for the delay, this is approved.
>
> We approve the action to re-license http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=801d469ad8b2b88f669326327df03d03200efbfb under LGPLv2.1 as requested.
>
> Best,
>
> Ken Lancaster
>
>
..snip..
Heya!
Sending this email to xen-devel mailing list.
Ken,
Thank you so much for helping out with this!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: James Pharaoh @ 2016-11-14 20:07 UTC (permalink / raw)
To: Zygo Blaxell, Austin S. Hemmelgarn; +Cc: Mark Fasheh, linux-btrfs
In-Reply-To: <20161114195102.GI21290@hungrycats.org>
On 14/11/16 20:51, Zygo Blaxell wrote:
> On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-11-14 13:22, James Pharaoh wrote:
>>> One thing I am keen to understand is if BTRFS will automatically ignore
>>> a request to deduplicate a file if it is already deduplicated? Given the
>>> performance I see when doing a repeat deduplication, it seems to me that
>>> it can't be doing so, although this could be caused by the CPU usage you
>>> mention above.
>>
>> What's happening is that the dedupe ioctl does a byte-wise comparison of the
>> ranges to make sure they're the same before linking them. This is actually
>> what takes most of the time when calling the ioctl, and is part of why it
>> takes longer the larger the range to deduplicate is. In essence, it's
>> behaving like an OS should and not trusting userspace to make reasonable
>> requests (which is also why there's a separate ioctl to clone a range from
>> another file instead of deduplicating existing data).
>
> - the extent-same ioctl could check to see which extents
> are referenced by the src and dst ranges, and return success
> immediately without reading data if they are the same (but
> userspace should already know this, or it's wasting a huge amount
> of time before it even calls the kernel).
Yes, this is what I am talking about. I believe I should be able to read
data about the BTRFS data structures and determine if this is the case.
I don't care if there are false matches, due to concurrent updates, but
there'll be a /lot/ of repeat deduplications unless I do this, because
even if the file is identical, the mtime etc hasn't changed, and I have
a record of previously doing a dedupe, there's no guarantee that the
file hasn't been rewritten in place (eg by rsync), and no way that I
know of to reliably detect if a file has been changed.
I am sure there are libraries out there which can look into the data
structures of a BTRFS file system, I haven't researched this in detail
though. I imagine that with some kind of lock on a BTRFS root, this
could be achieved by simply reading the data from the disk, since I
believe that everything is copy-on-write, so no existing data should be
overwritten until all roots referring to it are updated. Perhaps I'm
missing something though...
James
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-1-hdegoede@redhat.com>
Hi,
On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
> allwinner,pins = "PG3";
> };
>
> -&i2c1 {
> - icn8318: touchscreen at 40 {
> - compatible = "chipone,icn8318";
> - reg = <0x40>;
> - interrupt-parent = <&pio>;
> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> - pinctrl-names = "default";
> - pinctrl-0 = <&ts_wake_pin_p66>;
> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> - touchscreen-size-x = <800>;
> - touchscreen-size-y = <480>;
> - touchscreen-inverted-x;
> - touchscreen-swapped-x-y;
> - };
> -};
> -
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
> -
> - ts_wake_pin_p66: ts_wake_pin at 0 {
> - allwinner,pins = "PB3";
> - allwinner,function = "gpio_out";
> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> - };
> -
> };
>
> ®_usb0_vbus {
> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> };
>
> +&touchscreen {
> + compatible = "chipone,icn8318";
> + reg = <0x40>;
> + /* The P66 uses a different EINT then the reference design */
> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-swapped-x-y;
> + status = "okay";
> +};
> +
> &uart1 {
> /* The P66 uses the uart pins as gpios */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
> */
> #include "sunxi-reference-design-tablet.dtsi"
>
> +#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pwm/pwm.h>
>
> / {
> @@ -84,6 +85,23 @@
> };
>
> &i2c1 {
> + /*
> + * The gsl1680 is rated at 400KHz and it will not work reliable at
> + * 100KHz, this has been confirmed on multiple different q8 tablets.
> + * All other devices on this bus are also rated for 400KHz.
> + */
> + clock-frequency = <400000>;
> +
> + touchscreen: touchscreen {
> + interrupt-parent = <&pio>;
> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_power_pin>;
> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + /* Tablet dts must provide reg and compatible */
> + status = "disabled";
> + };
> +
> pcf8563: rtc at 51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> @@ -125,6 +143,13 @@
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
>
> + ts_power_pin: ts_power_pin {
> + allwinner,pins = "PB3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.
You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/7e78a172/attachment.sig>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <20161113192203.7101-1-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]
Hi,
On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
> allwinner,pins = "PG3";
> };
>
> -&i2c1 {
> - icn8318: touchscreen@40 {
> - compatible = "chipone,icn8318";
> - reg = <0x40>;
> - interrupt-parent = <&pio>;
> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> - pinctrl-names = "default";
> - pinctrl-0 = <&ts_wake_pin_p66>;
> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> - touchscreen-size-x = <800>;
> - touchscreen-size-y = <480>;
> - touchscreen-inverted-x;
> - touchscreen-swapped-x-y;
> - };
> -};
> -
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
> -
> - ts_wake_pin_p66: ts_wake_pin@0 {
> - allwinner,pins = "PB3";
> - allwinner,function = "gpio_out";
> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> - };
> -
> };
>
> ®_usb0_vbus {
> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> };
>
> +&touchscreen {
> + compatible = "chipone,icn8318";
> + reg = <0x40>;
> + /* The P66 uses a different EINT then the reference design */
> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-swapped-x-y;
> + status = "okay";
> +};
> +
> &uart1 {
> /* The P66 uses the uart pins as gpios */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
> */
> #include "sunxi-reference-design-tablet.dtsi"
>
> +#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pwm/pwm.h>
>
> / {
> @@ -84,6 +85,23 @@
> };
>
> &i2c1 {
> + /*
> + * The gsl1680 is rated at 400KHz and it will not work reliable at
> + * 100KHz, this has been confirmed on multiple different q8 tablets.
> + * All other devices on this bus are also rated for 400KHz.
> + */
> + clock-frequency = <400000>;
> +
> + touchscreen: touchscreen {
> + interrupt-parent = <&pio>;
> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_power_pin>;
> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + /* Tablet dts must provide reg and compatible */
> + status = "disabled";
> + };
> +
> pcf8563: rtc@51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> @@ -125,6 +143,13 @@
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
>
> + ts_power_pin: ts_power_pin {
> + allwinner,pins = "PB3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.
You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v10 3/3] drm/fence: add out-fences support
From: Daniel Vetter @ 2016-11-14 20:08 UTC (permalink / raw)
To: Brian Starkey
Cc: Gustavo Padovan, dri-devel, Linux Kernel Mailing List,
Daniel Stone, Rob Clark, Greg Hackmann, John Harrison,
Laurent Pinchart, Sean Paul, Stéphane Marchesin, m.chehab,
Maarten Lankhorst, Gustavo Padovan, Syrjala, Ville
In-Reply-To: <20161114145720.GB24412@e106950-lin.cambridge.arm.com>
On Mon, Nov 14, 2016 at 3:57 PM, Brian Starkey <brian.starkey@arm.com> wrote:
> I was just writing some internal docs, and it occurred to me that the
> out-fence implementation here doesn't seem to match what we discussed
> with Ville a few weeks back (which had completely slipped my mind).
>
> Did the idea of returning -1 fences for multiple commits within a
> frame get dropped? I didn't see any discussion further than that
> thread on v5 from October:
> http://lkml.iu.edu/hypermail/linux/kernel/1610.2/04727.html
Atm we only support a queue depth of 1, and not faster than vblank.
This was just discussions to make sure we're not drawing ourselves
into a corner with this uabi.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-2-hdegoede@redhat.com>
On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
>
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4197396f/attachment.sig>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <20161113192203.7101-2-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
>
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 02/21] specs/qcow2: do not use wording 'bitmap header'
From: John Snow @ 2016-11-14 20:08 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, qemu-block, qemu-devel
Cc: kwolf, famz, armbru, mreitz, stefanha, pbonzini, den
In-Reply-To: <1478715476-132280-3-git-send-email-vsementsov@virtuozzo.com>
On 11/09/2016 01:17 PM, Vladimir Sementsov-Ogievskiy wrote:
> A bitmap directory entry is sometimes called a 'bitmap header'. This
> patch leaves only one name - 'bitmap directory entry'. The name 'bitmap
> header' creates misunderstandings with 'qcow2 header' and 'qcow2 bitmap
> header extension' (which is extension of qcow2 header)
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> ---
> docs/specs/qcow2.txt | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> index dda53dd..8874e8c 100644
> --- a/docs/specs/qcow2.txt
> +++ b/docs/specs/qcow2.txt
> @@ -201,7 +201,7 @@ The fields of the bitmaps extension are:
>
> 8 - 15: bitmap_directory_size
> Size of the bitmap directory in bytes. It is the cumulative
> - size of all (nb_bitmaps) bitmap headers.
> + size of all (nb_bitmaps) bitmap directory entries.
>
> 16 - 23: bitmap_directory_offset
> Offset into the image file at which the bitmap directory
> @@ -426,8 +426,7 @@ Each bitmap saved in the image is described in a bitmap directory entry. The
> bitmap directory is a contiguous area in the image file, whose starting offset
> and length are given by the header extension fields bitmap_directory_offset and
> bitmap_directory_size. The entries of the bitmap directory have variable
> -length, depending on the lengths of the bitmap name and extra data. These
> -entries are also called bitmap headers.
> +length, depending on the lengths of the bitmap name and extra data.
>
> Structure of a bitmap directory entry:
>
>
Great improvement.
Reviewed-by: John Snow <jsnow@redhat.com>
^ permalink raw reply
* [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning
From: Tom Rini @ 2016-11-14 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <91683a9a-6f16-21dc-4295-d49f35acfce6@arm.com>
On Mon, Nov 14, 2016 at 07:43:40PM +0000, Andr? Przywara wrote:
[snip]
> On a related matter, I ran buildman on HEAD for armv8 today and GCC 6.2
> found quite some issues (will send out the fixes ASAP).
> So is there some buildbot somewhere that runs buildman? If yes, with
> what compilers?
What gcc-6.2 compilers are you using? The travis-ci setup is using the
Ubuntu 'Trusty' compilers, which are not that recent. I also have been
running debian/unstable in a chroot, but it's old enough of a copy to be
using gcc-5.3.1 currently. I'm going to kick off a new debootstrap
now'ish to see what toolchain versions I can get there. Do you know if
these gcc-6.2 problems you see would also show up for rpi3 in 64bit
mode? That's my current easiest test platform for aarch64. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/d9cf91c9/attachment.sig>
^ permalink raw reply
* [PATCH v2] mm, thb: propagation of conditional compilation in khugepaged.c
From: Jérémy Lefaure @ 2016-11-14 20:12 UTC (permalink / raw)
To: Andrew Morton, Kirill A. Shutemov; +Cc: linux-mm, Jérémy Lefaure
Commit b46e756f5e47 ("thp: extract khugepaged from mm/huge_memory.c")
moved code from huge_memory.c to khugepaged.c. Some of this code should
be compiled only when CONFIG_SYSFS is enabled but the condition around
this code was not moved into khugepaged.c. The result is a compilation
error when CONFIG_SYSFS is disabled:
mm/built-in.o: In function `khugepaged_defrag_store':
khugepaged.c:(.text+0x2d095): undefined reference to
`single_hugepage_flag_store'
mm/built-in.o: In function `khugepaged_defrag_show':
khugepaged.c:(.text+0x2d0ab): undefined reference to
`single_hugepage_flag_show'
This commit adds the #ifdef CONFIG_SYSFS around the code related to
sysfs.
Signed-off-by: JA(C)rA(C)my Lefaure <jeremy.lefaure@lse.epita.fr>
---
After having discuted with Hillf, I changed the subject to replace "thb" by
"mm, thb". I also rewrote the subject.
mm/khugepaged.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 728d779..87e1a7ca 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -103,6 +103,7 @@ static struct khugepaged_scan khugepaged_scan = {
.mm_head = LIST_HEAD_INIT(khugepaged_scan.mm_head),
};
+#ifdef CONFIG_SYSFS
static ssize_t scan_sleep_millisecs_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -295,6 +296,7 @@ struct attribute_group khugepaged_attr_group = {
.attrs = khugepaged_attr,
.name = "khugepaged",
};
+#endif /* CONFIG_SYSFS */
#define VM_NO_KHUGEPAGED (VM_SPECIAL | VM_HUGETLB)
--
2.10.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [Libtirpc-devel] [PATCH rpcbind] Move default state-dir to /run/rpcbind
From: Mike Frysinger @ 2016-11-14 20:12 UTC (permalink / raw)
To: Steve Dickson; +Cc: NeilBrown, Linux NFS Mailing List, libtirpc-devel
In-Reply-To: <8cbf8fc2-d358-37ca-75cf-c4e85e7aa3a4@RedHat.com>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On 14 Nov 2016 14:26, Steve Dickson wrote:
> On 11/14/2016 02:12 PM, Mike Frysinger wrote:
> > On 14 Nov 2016 10:09, NeilBrown wrote:
> >> On Sat, Nov 12 2016, Mike Frysinger wrote:
> >>> On 11 Nov 2016 14:36, NeilBrown wrote:
> >>>> rpcbind can save state in a file to allow restart without forgetting
> >>>> about running services.
> >>>>
> >>>> The default location is currently "/tmp" which is an over-used
> >>>> directory that isn't really suitable for system files.
> >>>> The modern preferences would be a subdirectory of "/run", which can
> >>>> be selected with a ./configure option. That subdirectory would still need
> >>>> to be created by something.
> >>> the portable path is /var/cache instead of /run. i don't think libtirpc
> >>> should be configuring itself to assume Linux by default.
> >> In principle I agree. But is /var/cache really a good choice?
> >> We don't want the state files to persist over a reboot, and I strongly
> >> suspect that /var/cache is designed to do exactly that.
> >>
> >> Are there agree standards that are broader than Linux that we can look
> >> to?
> >> FHS defines /var/run (or even /run) but I suspect it is linux-only.
> > /var/run should work across systems i believe. at least BSD's support it.
>
> In the Red Hat distos /var/run is a symbolic link to /run and the systemd
> folks have asked us to use /run instead of /var/run
yes, but we already know that's not an acceptable default -- /run today
is Linux specific. the question i was responding to here is if there's
a portable location that is better than /tmp.
Linux distros already know that for many packages they need to pass
flags to get /run behavior. rpcbind is no different.
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support
From: Maxime Ripard @ 2016-11-14 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114151457.GG27304@bill-the-cat>
On Mon, Nov 14, 2016 at 10:14:57AM -0500, Tom Rini wrote:
> On Mon, Nov 14, 2016 at 02:42:59PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Nov 11, 2016 at 11:16:39AM -0800, Moritz Fischer wrote:
> > > > +U_BOOT_DRIVER(ds2431) = {
> > > > + .name = "ds2431",
> > > > + .id = UCLASS_EEPROM,
> > > > + .ops = &ds2431_ops,
> > >
> > > Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?
> >
> > I don't know. I was kind of wondering why U-Boot relies on aliases so
> > much, especially when the Linux DT maintainers are saying that aliases
> > should be avoided entirely, and we'll won't be able to upstream those
> > changes.
>
> Bah. Do you have a pointer to some discussion about this handy?
Rob said this multiple times, but here is an example:
http://lkml.iu.edu/hypermail/linux/kernel/1609.1/00653.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/a0ffdcc3/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.