Re: [PATCH -mm 3/3] slub: make dead caches discard free slabs immediately
On Mon, Jan 26, 2015 at 03:55:29PM +0300, Vladimir Davydov wrote:
> To speed up further allocations SLUB may store empty slabs in per
> cpu/node partial lists instead of freeing them immediately. This
> prevents per memcg caches destruction, because kmem caches created for a
> memory cgroup are only destroyed after the last page charged to the
> cgroup is freed.
>
> To fix this issue, this patch resurrects approach first proposed in [1].
> It forbids SLUB to cache empty slabs after the memory cgroup that the
> cache belongs to was destroyed. It is achieved by setting kmem_cache's
> cpu_partial and min_partial constants to 0 and tuning put_cpu_partial()
> so that it would drop frozen empty slabs immediately if cpu_partial = 0.
>
> The runtime overhead is minimal. From all the hot functions, we only
> touch relatively cold put_cpu_partial(): we make it call
> unfreeze_partials() after freezing a slab that belongs to an offline
> memory cgroup. Since slab freezing exists to avoid moving slabs from/to
> a partial list on free/alloc, and there can't be allocations from dead
> caches, it shouldn't cause any overhead. We do have to disable
> preemption for put_cpu_partial() to achieve that though.
>
> The original patch was accepted well and even merged to the mm tree.
> However, I decided to withdraw it due to changes happening to the memcg
> core at that time. I had an idea of introducing per-memcg shrinkers for
> kmem caches, but now, as memcg has finally settled down, I do not see it
> as an option, because SLUB shrinker would be too costly to call since
> SLUB does not keep free slabs on a separate list. Besides, we currently
> do not even call per-memcg shrinkers for offline memcgs. Overall, it
> would introduce much more complexity to both SLUB and memcg than this
> small patch.
>
> Regarding to SLAB, there's no problem with it, because it shrinks
> per-cpu/node caches periodically. Thanks to list_lru reparenting, we no
> longer keep entries for offline cgroups in per-memcg arrays (such as
> memcg_cache_params->memcg_caches), so we do not have to bother if a
> per-memcg cache will be shrunk a bit later than it could be.
>
> [1] http://thread.gmane.org/gmane.linux.kernel.mm/118649/focus=118650
>
> Signed-off-by: Vladimir Davydov
> ---
> mm/slab.c|2 +-
> mm/slab.h|2 +-
> mm/slab_common.c | 15 +--
> mm/slob.c|2 +-
> mm/slub.c| 25 -
> 5 files changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 279c44d6d8e1..f0514df07b85 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2400,7 +2400,7 @@ static int __cache_shrink(struct kmem_cache *cachep)
> return (ret ? 1 : 0);
> }
>
> -void __kmem_cache_shrink(struct kmem_cache *cachep)
> +void __kmem_cache_shrink(struct kmem_cache *cachep, bool deactivate)
> {
> __cache_shrink(cachep);
> }
> diff --git a/mm/slab.h b/mm/slab.h
> index c036e520d2cf..041260197984 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -138,7 +138,7 @@ static inline unsigned long kmem_cache_flags(unsigned
> long object_size,
> #define CACHE_CREATE_MASK (SLAB_CORE_FLAGS | SLAB_DEBUG_FLAGS |
> SLAB_CACHE_FLAGS)
>
> int __kmem_cache_shutdown(struct kmem_cache *);
> -void __kmem_cache_shrink(struct kmem_cache *);
> +void __kmem_cache_shrink(struct kmem_cache *, bool);
> void slab_kmem_cache_release(struct kmem_cache *);
>
> struct seq_file;
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 6803639fdff0..472ab7fcffd4 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -549,10 +549,13 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup
> *memcg)
> {
> int idx;
> struct memcg_cache_array *arr;
> - struct kmem_cache *s;
> + struct kmem_cache *s, *c;
>
> idx = memcg_cache_id(memcg);
>
> + get_online_cpus();
> + get_online_mems();
> +
> mutex_lock(_mutex);
> list_for_each_entry(s, _caches, list) {
> if (!is_root_cache(s))
> @@ -560,9 +563,17 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup
> *memcg)
>
> arr = rcu_dereference_protected(s->memcg_params.memcg_caches,
> lockdep_is_held(_mutex));
> + c = arr->entries[idx];
> + if (!c)
> + continue;
> +
> + __kmem_cache_shrink(c, true);
> arr->entries[idx] = NULL;
> }
> mutex_unlock(_mutex);
> +
> + put_online_mems();
> + put_online_cpus();
> }
>
> void memcg_destroy_kmem_caches(struct mem_cgroup *memcg)
> @@ -646,7 +657,7 @@ void kmem_cache_shrink(struct kmem_cache *cachep)
> {
> get_online_cpus();
> get_online_mems();
> - __kmem_cache_shrink(cachep);
> + __kmem_cache_shrink(cachep, false);
> put_online_mems();
> put_online_cpus();
> }
> diff --git a/mm/slob.c b/mm/slob.c
> index 043a14b6ccbe..e63ff9d926dc 100644
> ---
Re: [PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment
On Mon, 26 Jan 2015, Kumar Amit Mehta wrote: > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent > with the code and the rest of the comment for this routine. This patch > fixes this typo in comment. > > Signed-off-by: Kumar Amit Mehta Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c > b/drivers/gpu/drm/i915/intel_fifo_underrun.c > index 77af512..04e248d 100644 > --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c > +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c > @@ -341,7 +341,7 @@ bool intel_set_pch_fifo_underrun_reporting(struct > drm_i915_private *dev_priv, > } > > /** > - * intel_pch_fifo_underrun_irq_handler - handle PCH fifo underrun interrupt > + * intel_cpu_fifo_underrun_irq_handler - handle CPU fifo underrun interrupt > * @dev_priv: i915 device instance > * @pipe: (CPU) pipe to set state for > * > -- > 2.1.0 > -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm: fix undefined reference to `.kernel_map_pages' on PPC builds
On Thu, Jan 22, 2015 at 10:45:51AM +0900, Joonsoo Kim wrote:
> On Wed, Jan 21, 2015 at 09:57:59PM +0900, Akinobu Mita wrote:
> > 2015-01-21 9:07 GMT+09:00 Andrew Morton :
> > > On Tue, 20 Jan 2015 15:01:50 -0800 j...@joshtriplett.org wrote:
> > >
> > >> On Tue, Jan 20, 2015 at 02:02:00PM -0600, Kim Phillips wrote:
> > >> > It's possible to configure DEBUG_PAGEALLOC without PAGE_POISONING on
> > >> > ppc. Fix building the generic kernel_map_pages() implementation in
> > >> > this case:
> > >> >
> > >> > LD init/built-in.o
> > >> > mm/built-in.o: In function `free_pages_prepare':
> > >> > mm/page_alloc.c:770: undefined reference to `.kernel_map_pages'
> > >> > mm/built-in.o: In function `prep_new_page':
> > >> > mm/page_alloc.c:933: undefined reference to `.kernel_map_pages'
> > >> > mm/built-in.o: In function `map_pages':
> > >> > mm/compaction.c:61: undefined reference to `.kernel_map_pages'
> > >> > make: *** [vmlinux] Error 1
> >
> > kernel_map_pages() is static inline function since commit 031bc5743f15
> > ("mm/debug-pagealloc: make debug-pagealloc boottime configurable").
> >
> > But there is old declaration in 'arch/powerpc/include/asm/cacheflush.h'.
> > Removing it or changing s/kernel_map_pages/__kernel_map_pages/ in this
> > header file or something can fix this problem?
> >
> > The architecture which has ARCH_SUPPORTS_DEBUG_PAGEALLOC
> > including PPC should not build mm/debug-pagealloc.o
>
> Yes, architecture with ARCH_SUPPORTS_DEBUG_PAGEALLOC should not build
> mm/debug-pagealloc.o. I attach the patch to remove old declaration.
> I hope it will fix Kim's problem.
>
> -->8--
> >From 7cb9d1ed8a785df152cb8934e187031c8ebd1bb2 Mon Sep 17 00:00:00 2001
> From: Joonsoo Kim
> Date: Thu, 22 Jan 2015 10:28:58 +0900
> Subject: [PATCH] mm/debug_pagealloc: fix build failure on ppc and some other
> archs
>
> Kim Phillips reported following build failure.
>
> LD init/built-in.o
> mm/built-in.o: In function `free_pages_prepare':
> mm/page_alloc.c:770: undefined reference to `.kernel_map_pages'
> mm/built-in.o: In function `prep_new_page':
> mm/page_alloc.c:933: undefined reference to `.kernel_map_pages'
> mm/built-in.o: In function `map_pages':
> mm/compaction.c:61: undefined reference to `.kernel_map_pages'
> make: *** [vmlinux] Error 1
>
> Reason for this problem is that commit 031bc5743f15
> ("mm/debug-pagealloc: make debug-pagealloc boottime configurable") forgot
> to remove old declaration of kernel_map_pages() in some architectures.
> This patch removes them to fix build failure.
>
> Reported-by: Kim Phillips
> Signed-off-by: Joonsoo Kim
Hello, Andrew.
Could you take this patch?
This patch is also needed to fix build failure.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM: shmobile: emev2-kzm9d: Add PFC information for uart1
On Sun, Jan 18, 2015 at 1:20 PM, Niklas Söderlund wrote:
> Configure the pinmux on kzm9d to use the serial connector for uart1.
>
> Signed-off-by: Niklas Söderlund
Acked-by: Linus Walleij
> + {
> + uart1_pins: uart@e103 {
> + renesas,groups = "uart1_ctrl", "uart1_data";
> + renesas,function = "uart1";
> + };
> +};
Would be nice if the PFC driver could be augmented to also accept the
now standard bindings "groups" and "function" simply :) we're adding parse
functions for those to the core.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] ARM: shmobile: emev2: Add PFC information to emev2.dtsi
On Sun, Jan 18, 2015 at 1:20 PM, Niklas Söderlund wrote: > With this information all GPIOs can make use of the PFC functionality. > > Signed-off-by: Niklas Söderlund Acked-by: Linus Walleij Pls take this through the shmobile tree.' Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] sh-pfc: Add emev2 pinmux support
On Sun, Jan 25, 2015 at 2:49 PM, Niklas Söderlund wrote: > Add PFC support for the EMMA Mobile EV2 SoC including pin groups for > on-chip devices. > > Signed-off-by: Niklas Söderlund This v3 version applied with Laurent's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] sh-pfc: add macro to define pinmux without function
On Sun, Jan 18, 2015 at 1:20 PM, Niklas Söderlund wrote: > Used to define pinmux configurations where the pinmux function have no > representation in the configuration registers but instead solely depends > on a group selection. > > Signed-off-by: Niklas Söderlund Patch applied with Laurent's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: futex(2) man page update help request
Hello Torvald, On 01/24/2015 02:12 PM, Torvald Riegel wrote: > On Sat, 2015-01-24 at 12:35 +0100, Thomas Gleixner wrote: >> So we should never see -EINTR in the case of a spurious wakeup here. >> >> But, here is the not so good news: >> >> I did some archaeology. The restart handling of futex_wait() got >> introduced in kernel 2.6.22, so anything older than that will have >> the spurious -EINTR issues. >> >> futex_wait_pi() always had the restart handling and glibc folks back >> then (2006) requested that it should never return -EINTR, so it >> unconditionally restarts the syscall whether a signal had been >> delivered or not. >> >> So kernels >= 2.6.22 should never return -EINTR spuriously. If that >> happens it's a bug and needs to be fixed. > > Thanks for looking into this. > > Michael, can you include the above in the documentation please? This is > useful for userspace code like glibc that expects a minimum kernel > version. Thanks! I've added some text to my draft to cover this point. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] c8c06efa8b5: -7.6% unixbench.score
Hi, Davidlohr, Any update on this? The latest news I gotten is that you finally reproduced this. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc//map_files/ and make it readable
On Mon, Jan 26, 2015 at 04:15:26PM -0800, Kees Cook wrote: > > > > akpm3:/usr/src/25> grep -r map_files Documentation > > If akpm's comments weren't clear: this needs to be fixed. Everything > in /proc should appear in Documentation. I'll do that. > > The 640708a2cff7f81 changelog says: > > > > : This one behaves similarly to the /proc//fd/ one - it contains > > : symlinks one for each mapping with file, the name of a symlink is > > : "vma->vm_start-vma->vm_end", the target is the file. Opening a > > symlink > > : results in a file that point exactly to the same inode as them vma's > > one. > > : > > : For example the ls -l of some arbitrary /proc//map_files/ > > : > > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 > > -> /lib64/libc-2.5.so > > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 > > -> /lib64/libselinux.so.1 > > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 > > -> /lib64/libacl.so.1.1.0 > > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 > > -> /lib64/librt-2.5.so > > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 > > -> /lib64/ld-2.5.so > > How is mmap offset represented in this output? We're printing vm_area_struct:[vm_start;vm_end] only. > > afacit this info is also available in /proc/pid/maps, so things > > shouldn't get worse if the /proc/pid/map_files permissions are at least > > as restrictive as the /proc/pid/maps permissions. Is that the case? > > (Please add to changelog). > > Both maps and map_files uses ptrace_may_access (via mm_acces) with > PTRACE_MODE_READ, so I'm happy from a info leak perspective. > > Are mount namespaces handled in this output? Could you clarify this moment, i'm not sure i get it. > > > There's one other problem here: we're assuming that the map_files > > implementation doesn't have bugs. If it does have bugs then relaxing > > permissions like this will create new vulnerabilities. And the > > map_files implementation is surprisingly complex. Is it bug-free? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mm/page_alloc: expands broken freepage to proper buddy list when steal
On 12/10/2014 07:38 AM, Joonsoo Kim wrote: > After your patch is merged, I will resubmit these on top of it. Hi Joonsoo, my page stealing patches are now in -mm so are you planning to resubmit this? At least patch 1 is an obvious bugfix, and patch 4 a clear compaction overhead reduction. Those don't need to wait for the rest of the series. If you are busy with other stuff, I can also resend those two myself if you want. Thanks, Vlastimil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ion:change ion_cma_allocate return error value
On Tue, Jan 27, 2015 at 02:04:21PM +0800, Wang, Yalin wrote: > This patch change the error return value from -1 to -ENOMEM, > so that userspace can get the correct errno, otherwise, > -1 will be -EPERM, userspace will print permission deny for allocation > failure. > > Signed-off-by: Yalin Wang Looks good. Reviewed-by: Dan Carpenter regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: clocksource: fix compile of asm9260_timer driver on ARCH=parisc
make sure this driver depends on GENERIC_CLOCKEVENTS
compiler error was found by kbuild test robot:
>> drivers/clocksource/asm9260_timer.c:114:14: warning: its scope is only this
>> definition or declaration, which is probably not what you want
>> drivers/clocksource/asm9260_timer.c:124:16: warning: 'struct
>> clock_event_device' declared inside parameter list
struct clock_event_device *evt)
>> drivers/clocksource/asm9260_timer.c:124:16: warning: 'enum clock_event_mode'
>> declared inside parameter list
>> drivers/clocksource/asm9260_timer.c:123:58: error: parameter 1 ('mode') has
>> incomplete type
static void asm9260_timer_set_mode(enum clock_event_mode mode,
Signed-off-by: Oleksij Rempel
---
drivers/clocksource/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 13b8152..bfaaae4 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -231,6 +231,7 @@ config CLKSRC_MIPS_GIC
config ASM9260_TIMER
bool "Alphascale ASM9260 timer driver"
+ depends on GENERIC_CLOCKEVENTS
select CLKSRC_MMIO
select CLKSRC_OF
default y if MACH_ASM9260
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc//map_files/ and make it readable
On Mon, Jan 26, 2015 at 10:50:23PM -0800, Andrew Morton wrote: > On Tue, 27 Jan 2015 09:46:47 +0300 Cyrill Gorcunov wrote: > > > > There's one other problem here: we're assuming that the map_files > > > implementation doesn't have bugs. If it does have bugs then relaxing > > > permissions like this will create new vulnerabilities. And the > > > map_files implementation is surprisingly complex. Is it bug-free? > > > > I didn't find any bugs in map-files (and we use it for long time already) > > so I think it is safe. > > You've been using map_files the way it was supposed to be used so no, > any bugs won't show up. What happens if you don your evil black hat > and use map_files in ways that weren't anticipated? Attack it? Hard to say, Andrew. If I found a way to exploit this feature for bad purpose for sure I would patch it out. At the moment I don't see any. Touching another process memory via file descriptor allows one to modify its contents but you have to be granted ptrace-may-access which i consider as enough for security. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
1 Unread Message From Reserve Bank
reply via{inquiryu...@blumail.org} Now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] iommu: Small fixes and cleanups
Hi Joerg, Thank you for the patches. On Tuesday 27 January 2015 00:50:26 Joerg Roedel wrote: > Hi, > > here are a couple of iommu fixes and cleanups to fix compile > errors and some warnings on ARM and PPC. For the whole series, Acked-by: Laurent Pinchart > Regards, > > Joerg > > Joerg Roedel (4): > iommu: Make more drivers depend on COMPILE_TEST > iommu/exynos: Make driver depend on REGULATOR > iommu/omap: Print phys_addr_t using %pa > iommu/fsl: Use %pa to print phys_addr_t > > drivers/iommu/Kconfig | 11 +++ > drivers/iommu/fsl_pamu.c | 4 ++-- > drivers/iommu/omap-iommu.c | 2 +- > 3 files changed, 10 insertions(+), 7 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3]PM/Sleep: Timer quiesce in freeze state
On 2015/1/26 22:45, Rafael J. Wysocki wrote: > On Monday, January 26, 2015 03:15:43 PM Thomas Gleixner wrote: >> On Mon, 26 Jan 2015, Rafael J. Wysocki wrote: >> >>> On Monday, January 26, 2015 10:40:24 AM Thomas Gleixner wrote: On Mon, 26 Jan 2015, Li, Aubrey wrote: > On 2015/1/22 18:15, Thomas Gleixner wrote: >> Can we please stop adding more crap to that notifier thing? I rather >> see that go away than being expanded. > > Are you referring to FREEZE_PREPARE or remove all of FREEZE staff at all? > > What's the disadvantage of adding more notifier? clockevents_notify() is not a notifier. Its a multiplex call and I want to get rid of it and replace it with explicit functions. >>> >>> OK, so perhaps we need to move _SUSPEND/_RESUME out of there to start with? >>> >>> As far as I can say, clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL) and >>> clockevents_notify(CLOCK_EVT_NOTIFY_RESUME, NULL) are each only called from >>> one place and moreover, since they are in syscore_ops, we don't need any >>> locking around them. >>> >>> So what about the patch below? >> >> I'm cleaning up the whole replacement of notify. The stuff below is >> part of it. >> >>> >>> - clockevents_notify(CLOCK_EVT_NOTIFY_SUSPEND, NULL); >>> + tick_suspend(); >>> + tick_suspend_broadcast(); >> >> That's exactly the stuff I don't want to see. Blind code >> move. > > At least it's clear what the patch does. :-) > >> tick_suspend_broadcast() wants to be called from tick_suspend(). > > OK > >> Still compiling and testing a gazillion of combinations. > > OK, so it looks like we need to wait with the suspend to idle changes until > this lands. Please cc the patches to me when you post. I'll refine the patch after that. Thanks, -Aubrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
Hi Russell!
On 21 January 2015 at 23:01, Russell King - ARM Linux
wrote:
> On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote:
>> +static int calc_constraints(struct device *dev,
>> + struct dma_buf_constraints *calc_cons)
>> +{
>> + struct dma_buf_constraints cons = *calc_cons;
>> +
>> + cons.dma_mask &= dma_get_mask(dev);
>
> I don't think this makes much sense when you consider that the DMA
> infrastructure supports buses with offsets. The DMA mask is th
> upper limit of the _bus_ specific address, it is not a mask per-se.
>
> What this means is that &= is not the right operation. Moreover,
> simply comparing masks which could be from devices on unrelated
> buses doesn't make sense either.
>
> However, that said, I don't have an answer for what you want to
> achieve here.
Thanks for your comments! I suppose in that case, I will leave out the
*dma_masks from this constraints information for now; we can re-visit
it when a specific use case really needs information about the
dma-masks of the attached devices.
I will post an updated patch-set soon.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
--
Thanks and regards,
Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 4/6] devicetree: Add new SKY81452 backlight binding
On Fri, Jan 23, 2015 at 03:28:33PM +0900, gyun...@gmail.com wrote:
> From: Gyungoh Yoo
>
> Signed-off-by: Gyungoh Yoo
> Acked-by: Bryan Wu
The existing Ack is only for backlight driver.
DT Ack please.
> ---
> Changes v10:
> Nothing
>
> Changes v9:
> Nothing
>
> Changes v8:
> Renamed property names for backlight with vendor prefix
> Modified gpio-enable property to generic property for GPIO
> Made up the example for backlight DT
>
> Changes v7:
> Nothing
>
> Changes v6:
> Nothing
>
> Changes v5:
> Nothing
>
> Changes v4:
> Nothing
>
> Changes v3:
> Nothing
>
> Changes v2:
> Added reg attribute for I2C slave address
>
> .../video/backlight/sky81452-backlight.txt | 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
>
> diff --git
> a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> new file mode 100644
> index 000..8daebf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> @@ -0,0 +1,29 @@
> +SKY81452-backlight bindings
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452-backlight"
> +
> +Optional properties:
> +- name : Name of backlight device. Default is
> 'lcd-backlight'.
> +- gpios : GPIO to use to EN pin.
> + See Documentation/devicetree/bindings/gpio/gpio.txt
> +- skyworks,en-channels : Enable mask for current sink channel 1 to 6.
> +- skyworks,ignore-pwm: Ignore both PWM input
> +- skyworks,dpwm-mode : Enable DPWM dimming mode, otherwise Analog dimming.
> +- skyworks,phase-shift : Enable phase shift mode
> +- skyworks,ovp-level : Over-voltage protection level.
> + Should be between 14 or 28V.
> +- skyworks,short-detection-threshold : It should be one of 4, 5, 6 and 7V.
> +- skyworks,current-limit : It should be 2300mA or 2750mA.
> +
> +Example:
> +
> + backlight {
> + compatible = "skyworks,sky81452-backlight";
> + name = "pwm-backlight";
> + skyworks,en-channels = <0x3f>;
> + skyworks,ignore-pwm;
> + skyworks,phase-shift;
> + skyworks,ovp-level = <20>;
> + skyworks,current-limit = <2300>;
> + };
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH mtd] mtd:devices: Add Altera EPCQ Driver
On Tue, Jan 20, 2015 at 10:05 AM, Viet Nga Dao wrote:
> On Thu, Jan 15, 2015 at 5:27 PM, Viet Nga Dao wrote:
>> On Tue, Jan 13, 2015 at 11:33 AM, Brian Norris
>> wrote:
>>> On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote:
From: Viet Nga Dao
Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and
EPCS flash chips. This patch adds driver for these devices.
Signed-off-by: Viet Nga Dao
>>>
>>> This drivers seems awfully similar to (and so I infer it is likely
>>> copy-and-pasted from) m25p80.c / spi-nor.c. Do you think it can be
>>> rewritten as a SPI NOR driver, under drivers/mtd/spi-nor/ ? It looks
>>> like these flash share most (all?) the same basic opcodes.
>>>
>> For Altera EPCQ flashes, almost operations are performed underline
>> hardware.
>
>Right, that's understandable. But that's what spi-nor.c was designed
>for: implementing hardware-specific functionality that is targeted
>directly at SPI flash. Did you take a look at the callbacks available in
>'struct spi_nor'?
>
>>Software only able to perform the following through
>> registers:
>> - read status register
>> - read id
>> - write status registers bit SR_BP0,SR_BP1, SR_BP2,SR_BP3, SR_TB
>> (http://www.altera.com.my/literature/hb/cfg/cfg_cf52012.pdf)
>
>OK
>
>> For read/write data: all the operations like QUAD_READ/WRITE,
>> FAST_READ/WRITE are handled by hardware as well. From software point
>> of view, there is no difference between these 2 modes.
>
>OK, so you don't have to hook up the dual/quad mode infrastructure. And
>you'd just implement dead-simple spi_nor.{read,write,erase}() callbacks.
>
>> That is why if rewrite the drivers to follow spi-nor structure, it
>> will require extra decoding works for the only few used opcodes.
>>
>I think you'd only have some very trivial work here.
>
>There would be some small work to reintroduce a properly-replaceable ID
>table, and callbacks like ->lock() and ->unlock(), but those should be
>implemented in spi-nor.c sooner or later anyway.
>
I am trying to modify the code to follow your recommendation. However,
for lock and unlock functions, i have to implement it in spi_nor.c ,
am i right? If yes, currently we already have existing spi_nor_lock
and spi_nor_unlock functions but they could not apply for my driver.
Should i create a new functions named altera_epcq_lock and unlock and
then map it to callback functions or i should the put those code
sunder existing spi_nor_lock/unlock?
>Anyway, if you take another look at spi-nor.{c,h} and determine that
>it's too difficult, then I suppose I don't mind accepting your driver
>under its current design. Your hardware is pretty esoteric anyway, the
>driver is still pretty simple, and it'll never be supporting any common
>SPI NOR vendors (right?), so it's not too big of a maintenance problem,
>I expect. But I do want to make sure that we don't copy/paste to repeat
>the mistakes of old drivers. As I noted already, your driver inherited
>some of the quirks of the old m25p80.c code.
>
>So please, give drivers/mtd/spi-nor/ another look, and then we can
>resume this discussion.
---
.../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
drivers/mtd/devices/Kconfig| 12 +
drivers/mtd/devices/Makefile |2 +-
drivers/mtd/devices/altera_epcq.c | 804
drivers/mtd/devices/altera_epcq.h | 130
5 files changed, 992 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
create mode 100644 drivers/mtd/devices/altera_epcq.c
create mode 100644 drivers/mtd/devices/altera_epcq.h
diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
new file mode 100644
index 000..d14f50e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
@@ -0,0 +1,45 @@
+* MTD Altera EPCQ driver
+
+Required properties:
+- compatible: Should be "altr,epcq-1.0"
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ "csr_base": Should contain the register configuration base address
+ "data_base": Should contain the data base address
+- is-epcs: boolean type.
+ If present, the device contains EPCS flashes.
+ Otherwise, it contains EPCQ flashes.
+- #address-cells: Must be <1>.
+- #size-cells: Must be <0>.
+- flash device tree subnode, there must be a node with the following
fields:
>>>
>>> These subnodes definitely require a 'compatible' string. Perhaps they
>>> should be used to differentiate EPCS vs. EPCQ. Does "is-epcs" really
>>> need
[PATCH 4/7] rtlwifi: Remove unused RTL_SUPPORTED_CTRL_FILTER define
Signed-off-by: Priit Laes --- drivers/net/wireless/rtlwifi/core.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/core.h b/drivers/net/wireless/rtlwifi/core.h index 624e1dc..3b37557 100644 --- a/drivers/net/wireless/rtlwifi/core.h +++ b/drivers/net/wireless/rtlwifi/core.h @@ -33,8 +33,6 @@ FIF_FCSFAIL | \ FIF_BCN_PRBRESP_PROMISC) -#define RTL_SUPPORTED_CTRL_FILTER 0xFF - extern const struct ieee80211_ops rtl_ops; void rtl_fw_cb(const struct firmware *firmware, void *context); void rtl_addr_delay(u32 addr); -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] rtlwifi: Remove unused RF6052_MAX_REG define
Signed-off-by: Priit Laes --- drivers/net/wireless/rtlwifi/rtl8188ee/rf.h | 1 - drivers/net/wireless/rtlwifi/rtl8192ce/rf.h | 1 - drivers/net/wireless/rtlwifi/rtl8192cu/rf.h | 1 - drivers/net/wireless/rtlwifi/rtl8192de/def.h | 1 - drivers/net/wireless/rtlwifi/rtl8192ee/rf.h | 1 - drivers/net/wireless/rtlwifi/rtl8723ae/rf.h | 1 - drivers/net/wireless/rtlwifi/rtl8723be/rf.h | 1 - drivers/net/wireless/rtlwifi/rtl8821ae/rf.h | 1 - 8 files changed, 8 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/rf.h b/drivers/net/wireless/rtlwifi/rtl8188ee/rf.h index 5c1472d..0eca030 100644 --- a/drivers/net/wireless/rtlwifi/rtl8188ee/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8188ee/rf.h @@ -27,7 +27,6 @@ #define __RTL92C_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F void rtl88e_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/rf.h b/drivers/net/wireless/rtlwifi/rtl8192ce/rf.h index d8fe68b..ebd72ca 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ce/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8192ce/rf.h @@ -31,7 +31,6 @@ #define __RTL92C_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F #define RF6052_MAX_PATH2 void rtl92ce_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.h b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.h index 11b439d..6f987de 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.h @@ -31,7 +31,6 @@ #define __RTL92CU_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F #define RF6052_MAX_PATH2 void rtl92cu_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/def.h b/drivers/net/wireless/rtlwifi/rtl8192de/def.h index 4ca1fe1..0a443ed 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192de/def.h +++ b/drivers/net/wireless/rtlwifi/rtl8192de/def.h @@ -35,7 +35,6 @@ #defineMAX_MSS_DENSITY_1T 0x0A #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F #define RF6052_MAX_PATH2 #definePHY_RSSI_SLID_WIN_MAX 100 diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/rf.h b/drivers/net/wireless/rtlwifi/rtl8192ee/rf.h index 8bdeed3..039c013 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192ee/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8192ee/rf.h @@ -27,7 +27,6 @@ #define __RTL92E_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F void rtl92ee_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/rf.h b/drivers/net/wireless/rtlwifi/rtl8723ae/rf.h index f3f45b1..7b44ebc 100644 --- a/drivers/net/wireless/rtlwifi/rtl8723ae/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8723ae/rf.h @@ -27,7 +27,6 @@ #define __RTL8723E_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F void rtl8723e_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/rf.h b/drivers/net/wireless/rtlwifi/rtl8723be/rf.h index a6fea10..f423e15 100644 --- a/drivers/net/wireless/rtlwifi/rtl8723be/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8723be/rf.h @@ -27,7 +27,6 @@ #define __RTL8723BE_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F void rtl8723be_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/rf.h b/drivers/net/wireless/rtlwifi/rtl8821ae/rf.h index d9582ee..efd22bd 100644 --- a/drivers/net/wireless/rtlwifi/rtl8821ae/rf.h +++ b/drivers/net/wireless/rtlwifi/rtl8821ae/rf.h @@ -27,7 +27,6 @@ #define __RTL8821AE_RF_H__ #define RF6052_MAX_TX_PWR 0x3F -#define RF6052_MAX_REG 0x3F void rtl8821ae_phy_rf6052_set_bandwidth(struct ieee80211_hw *hw, u8 bandwidth); -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] rtlwifi: Remove unused defines from base.h
Signed-off-by: Priit Laes
---
drivers/net/wireless/rtlwifi/base.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.h
b/drivers/net/wireless/rtlwifi/base.h
index 982f245..ea3e3fc 100644
--- a/drivers/net/wireless/rtlwifi/base.h
+++ b/drivers/net/wireless/rtlwifi/base.h
@@ -45,9 +45,6 @@ enum ap_peer {
#define RTL_TX_DESC_SIZE 32
#define RTL_TX_HEADER_SIZE (RTL_TX_DESC_SIZE + RTL_TX_DUMMY_SIZE)
-#define HT_AMSDU_SIZE_4K 3839
-#define HT_AMSDU_SIZE_8K 7935
-
#define MAX_BIT_RATE_40MHZ_MCS15 300 /* Mbps */
#define MAX_BIT_RATE_40MHZ_MCS7150 /* Mbps */
@@ -61,9 +58,6 @@ enum ap_peer {
#define MAX_BIT_RATE_LONG_GI_1NSS_80MHZ_MCS9 390 /* Mbps */
#define MAX_BIT_RATE_LONG_GI_1NSS_80MHZ_MCS7 293 /* Mbps */
-#define RTL_RATE_COUNT_LEGACY 12
-#define RTL_CHANNEL_COUNT 14
-
#define FRAME_OFFSET_FRAME_CONTROL 0
#define FRAME_OFFSET_DURATION 2
#define FRAME_OFFSET_ADDRESS1 4
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc//map_files/ and make it readable
On Tue, 27 Jan 2015 09:46:47 +0300 Cyrill Gorcunov wrote: > > There's one other problem here: we're assuming that the map_files > > implementation doesn't have bugs. If it does have bugs then relaxing > > permissions like this will create new vulnerabilities. And the > > map_files implementation is surprisingly complex. Is it bug-free? > > I didn't find any bugs in map-files (and we use it for long time already) > so I think it is safe. You've been using map_files the way it was supposed to be used so no, any bugs won't show up. What happens if you don your evil black hat and use map_files in ways that weren't anticipated? Attack it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] rtlwifi: Remove unused defines from efuse.h
Signed-off-by: Priit Laes --- drivers/net/wireless/rtlwifi/efuse.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/efuse.h b/drivers/net/wireless/rtlwifi/efuse.h index fdab824..be02e78 100644 --- a/drivers/net/wireless/rtlwifi/efuse.h +++ b/drivers/net/wireless/rtlwifi/efuse.h @@ -40,12 +40,6 @@ #define PG_STATE_WORD_30x10 #define PG_STATE_DATA 0x20 -#define PG_SWBYTE_H0x01 -#define PG_SWBYTE_L0x02 - -#define _POWERON_DELAY_ -#define _PRE_EXECUTE_READ_CMD_ - #define EFUSE_REPEAT_THRESHOLD_3 #define EFUSE_ERROE_HANDLE 1 -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] rtlwifi: Remove unused defines from driver-specific def.h
HAL_RETRY_LIMIT_*
RESET_DELAY_8185
RT_IBSS_INT_MASKS
RT_AC_INT_MASKS
NUM_OF_*
BT_*,
MAX_{LINES,BYTES}_*,
*_THREE_WIRE
*_QUEUE related
Signed-off-by: Priit Laes
---
drivers/net/wireless/rtlwifi/rtl8188ee/def.h | 41
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 41
drivers/net/wireless/rtlwifi/rtl8192de/def.h | 38 --
drivers/net/wireless/rtlwifi/rtl8192se/def.h | 1 -
drivers/net/wireless/rtlwifi/rtl8723ae/def.h | 41
drivers/net/wireless/rtlwifi/rtl8821ae/def.h | 41
6 files changed, 203 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/def.h
b/drivers/net/wireless/rtlwifi/rtl8188ee/def.h
index d9ea9d0..0532b98 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/def.h
@@ -26,53 +26,12 @@
#ifndef __RTL92C_DEF_H__
#define __RTL92C_DEF_H__
-#define HAL_RETRY_LIMIT_INFRA 48
-#define HAL_RETRY_LIMIT_AP_ADHOC 7
-
-#define RESET_DELAY_8185 20
-
-#define RT_IBSS_INT_MASKS (IMR_BCNINT | IMR_TBDOK | IMR_TBDER)
-#define RT_AC_INT_MASKS(IMR_VIDOK | IMR_VODOK |
IMR_BEDOK|IMR_BKDOK)
-
-#define NUM_OF_FIRMWARE_QUEUE 10
-#define NUM_OF_PAGES_IN_FW 0x100
-#define NUM_OF_PAGE_IN_FW_QUEUE_BK 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_BE 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_VI 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_VO 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_HCCA 0x0
-#define NUM_OF_PAGE_IN_FW_QUEUE_CMD0x0
-#define NUM_OF_PAGE_IN_FW_QUEUE_MGNT 0x02
-#define NUM_OF_PAGE_IN_FW_QUEUE_HIGH 0x02
-#define NUM_OF_PAGE_IN_FW_QUEUE_BCN0x2
-#define NUM_OF_PAGE_IN_FW_QUEUE_PUB0xA1
-
-#define NUM_OF_PAGE_IN_FW_QUEUE_BK_DTM 0x026
-#define NUM_OF_PAGE_IN_FW_QUEUE_BE_DTM 0x048
-#define NUM_OF_PAGE_IN_FW_QUEUE_VI_DTM 0x048
-#define NUM_OF_PAGE_IN_FW_QUEUE_VO_DTM 0x026
-#define NUM_OF_PAGE_IN_FW_QUEUE_PUB_DTM0x00
-
-#define MAX_LINES_HWCONFIG_TXT 1000
-#define MAX_BYTES_LINE_HWCONFIG_TXT256
-
-#define SW_THREE_WIRE 0
-#define HW_THREE_WIRE 2
-
-#define BT_DEMO_BOARD 0
-#define BT_QA_BOARD1
-#define BT_FPGA2
-
#define HAL_PRIME_CHNL_OFFSET_DONT_CARE0
#define HAL_PRIME_CHNL_OFFSET_LOWER1
#define HAL_PRIME_CHNL_OFFSET_UPPER2
-#define MAX_H2C_QUEUE_NUM 10
-
#define RX_MPDU_QUEUE 0
#define RX_CMD_QUEUE 1
-#define RX_MAX_QUEUE 2
-#define AC2QUEUEID(_AC)(_AC)
#defineC2H_RX_CMD_HDR_LEN 8
#defineGET_C2H_CMD_CMD_LEN(__prxhdr) \
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
index 9b660df..690a7a1 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/def.h
@@ -30,59 +30,18 @@
#ifndef __RTL92C_DEF_H__
#define __RTL92C_DEF_H__
-#define HAL_RETRY_LIMIT_INFRA 48
-#define HAL_RETRY_LIMIT_AP_ADHOC 7
-
#definePHY_RSSI_SLID_WIN_MAX 100
#definePHY_LINKQUALITY_SLID_WIN_MAX20
#definePHY_BEACON_RSSI_SLID_WIN_MAX10
-#define RESET_DELAY_8185 20
-
-#define RT_IBSS_INT_MASKS (IMR_BCNINT | IMR_TBDOK | IMR_TBDER)
-#define RT_AC_INT_MASKS(IMR_VIDOK | IMR_VODOK |
IMR_BEDOK|IMR_BKDOK)
-
-#define NUM_OF_FIRMWARE_QUEUE 10
-#define NUM_OF_PAGES_IN_FW 0x100
-#define NUM_OF_PAGE_IN_FW_QUEUE_BK 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_BE 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_VI 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_VO 0x07
-#define NUM_OF_PAGE_IN_FW_QUEUE_HCCA 0x0
-#define NUM_OF_PAGE_IN_FW_QUEUE_CMD0x0
-#define NUM_OF_PAGE_IN_FW_QUEUE_MGNT 0x02
-#define NUM_OF_PAGE_IN_FW_QUEUE_HIGH 0x02
-#define NUM_OF_PAGE_IN_FW_QUEUE_BCN0x2
-#define NUM_OF_PAGE_IN_FW_QUEUE_PUB0xA1
-
-#define
Re: [PATCH -rt] rtmutex: enable deadlock detection in the ww_mutex_lock functions
You should probably CC -rt maintainers when submitting a -rt patch. On Tue, 2015-01-27 at 03:53 -0200, Gustavo Bittencourt wrote: > According the ww-mutex-design.txt documentation, the > ww_mutex_lock_interruptible and ww_mutex_lock functions should return > -EDEADLK when faced with a deadlock. To do so, the flag detect_deadlock in > the rt_mutex_slowlock calls should be enabled. This patch corrects potential > deadlocks when running PREEMPT_RT with nouveau driver. > > Kernel v3.14-rt > > Signed-off-by: Gustavo Bittencourt > --- > kernel/locking/rtmutex.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > index 6c40660..3f6ef91 100644 > --- a/kernel/locking/rtmutex.c > +++ b/kernel/locking/rtmutex.c > @@ -1965,7 +1965,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, > struct ww_acquire_ctx *ww_c > might_sleep(); > > mutex_acquire(>base.dep_map, 0, 0,_RET_IP_); > - ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 0, > ww_ctx); > + ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 1, > ww_ctx); > if (ret) > mutex_release(>base.dep_map, 1,_RET_IP_); > else if (!ret && ww_ctx->acquired > 1) > @@ -1984,7 +1984,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct > ww_acquire_ctx *ww_ctx) > > mutex_acquire_nest(>base.dep_map, 0, 0, _ctx->dep_map, > _RET_IP_); > - ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, > 0, ww_ctx); > + ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, > 1, ww_ctx); > if (ret) > mutex_release(>base.dep_map, 1,_RET_IP_); > else if (!ret && ww_ctx->acquired > 1) > -- 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] rtlwifi: Remove unused defines from rtl8192cu driver
Signed-off-by: Priit Laes --- drivers/net/wireless/rtlwifi/rtl8192cu/hw.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h index c1e33b0..6758808 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h @@ -32,8 +32,6 @@ #define H2C_RA_MASK6 -#define LLT_POLLING_LLT_THRESHOLD 20 -#define LLT_POLLING_READY_TIMEOUT_COUNT100 #define LLT_LAST_ENTRY_OF_TX_PKT_BUFFER255 #define RX_PAGE_SIZE_REG_VALUE PBP_128 -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] rtlwifi: Remove unused defines from cam.h
Signed-off-by: Priit Laes --- drivers/net/wireless/rtlwifi/cam.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/cam.h b/drivers/net/wireless/rtlwifi/cam.h index 3550808..e2e647d 100644 --- a/drivers/net/wireless/rtlwifi/cam.h +++ b/drivers/net/wireless/rtlwifi/cam.h @@ -28,13 +28,11 @@ #define CAM_CONTENT_COUNT 8 -#define CFG_DEFAULT_KEYBIT(5) #define CFG_VALID BIT(15) #define PAIRWISE_KEYIDX0 #define CAM_PAIRWISE_KEY_POSITION 4 -#defineCAM_CONFIG_USEDK1 #defineCAM_CONFIG_NO_USEDK 0 void rtl_cam_reset_all_entry(struct ieee80211_hw *hw); -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc//map_files/ and make it readable
On Mon, Jan 26, 2015 at 03:43:46PM -0800, Andrew Morton wrote: > > > > Looks good to me, thanks! Though I would really appreciate if someone > > from security camp take a look as well. > > hm, who's that. Kees comes to mind. yup, I managed to forget CC him. > > And reviewers' task would be a heck of a lot easier if they knew what > /proc/pid/map_files actually does. This: > > akpm3:/usr/src/25> grep -r map_files Documentation > akpm3:/usr/src/25> > > does not help. Sigh. Imagine, for some reason I though we've the docs for that entry, probably i though that way because of many fdinfo snippets i've putted into /proc docs. my bad, sorry. I'll try to prepare docs today. > The 640708a2cff7f81 changelog says: > > : This one behaves similarly to the /proc//fd/ one - it contains > : symlinks one for each mapping with file, the name of a symlink is > : "vma->vm_start-vma->vm_end", the target is the file. Opening a symlink > : results in a file that point exactly to the same inode as them vma's > one. > : > : For example the ls -l of some arbitrary /proc//map_files/ > : > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 -> > /lib64/libc-2.5.so > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 -> > /lib64/libselinux.so.1 > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 -> > /lib64/libacl.so.1.1.0 > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 -> > /lib64/librt-2.5.so > : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 -> > /lib64/ld-2.5.so > > afacit this info is also available in /proc/pid/maps, so things > shouldn't get worse if the /proc/pid/map_files permissions are at least > as restrictive as the /proc/pid/maps permissions. Is that the case? > (Please add to changelog). > > There's one other problem here: we're assuming that the map_files > implementation doesn't have bugs. If it does have bugs then relaxing > permissions like this will create new vulnerabilities. And the > map_files implementation is surprisingly complex. Is it bug-free? I didn't find any bugs in map-files (and we use it for long time already) so I think it is safe. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/2] perf symbols: Ignore mapping symbols on aarch64
Aarch64 ELF files use mapping symbols with special names $x, $d
to identify regions of Aarch64 code (see Aarch64 ELF ABI - "ARM
IHI 0056B", section "4.5.4 Mapping symbols").
The patch filters out these symbols at load time, similar to
"696b97a perf symbols: Ignore mapping symbols on ARM" changes
done for ARM before V8.
Also added handling of mapping symbols that has format
"$d." and similar for both cases.
Note we are not making difference between EM_ARM and
EM_AARCH64 mapping symbols instead code handles superset
of both.
Signed-off-by: Victor Kamensky
Acked-by: Will Deacon
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Avi Kivity
Cc: Masami Hiramatsu
Cc: Anton Blanchard
Cc: David Ahern
Cc: Will Deacon
Cc: Russell King
Cc: Dave Martin
---
tools/perf/util/symbol-elf.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 06fcd1b..8fc6e2f 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -856,10 +856,9 @@ int dso__load_sym(struct dso *dso, struct map *map,
/* Reject ARM ELF "mapping symbols": these aren't unique and
* don't identify functions, so will confuse the profile
* output: */
- if (ehdr.e_machine == EM_ARM) {
- if (!strcmp(elf_name, "$a") ||
- !strcmp(elf_name, "$d") ||
- !strcmp(elf_name, "$t"))
+ if (ehdr.e_machine == EM_ARM || ehdr.e_machine == EM_AARCH64) {
+ if (elf_name[0] == '$' && strchr("adtx", elf_name[1])
+ && (elf_name[2] == '\0' || elf_name[2] == '.'))
continue;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 0/2] perf symbols: debuglink and arm mapping symbols changes
Hi Folks, Here is third version of mini-series that addresses couple issues in perf symbols handling. Changes since V2: o Since V2 caused some controversy wrt aarch64/arm fixes [3], replace 'perf symbols: Ignore mapping symbols on aarch64' and 'perf symbols: improve abi compliance in arm mapping symbols handling with another version of almost equivalent single patch that was discussed on [1]. In new patch superset of aarch64 and arm mapping symbols handled by single code snippet, that is more aligned with other places where aarch64 and arm mapping symbols are handled. Changes since V1: o 'perf symbols: Ignore mapping symbols on aarch64': based on feedback from Will Deacon and Russell King [1] added code that handles ARM/Aarch64 mapping symbols like "$d.". Code uses similar snippet to handle ARM mapping symbols as in another places in kernel, but it has its own version of the code. Added proper Acked-by. o 'perf symbols: debuglink should take symfs option into account': based on feedback from David Ahern [2] picked more simple version that does not make malloced copy of 'filename', that makes patch simpler. Added proper 'Acked-and-tested-by'. [1] https://lkml.org/lkml/2015/1/13/507 [2] https://lkml.org/lkml/2015/1/13/508 [3] https://lkml.org/lkml/2015/1/22/382 Victor Kamensky (2): perf symbols: Ignore mapping symbols on aarch64 perf symbols: debuglink should take symfs option into account tools/perf/util/dso.c| 6 +++--- tools/perf/util/symbol-elf.c | 7 +++ 2 files changed, 6 insertions(+), 7 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/2] perf symbols: debuglink should take symfs option into account
Currently code that tries to read corresponding debug symbol
file from .gnu_debuglink section (DSO_BINARY_TYPE__DEBUGLINK)
does not take in account symfs option, so filename__read_debuglink
function cannot open ELF file, if symfs option is used.
Fix is to add proper handling of symfs as it is done in other
places: use __symbol__join_symfs function to get real file name
of target ELF file.
Signed-off-by: Victor Kamensky
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Adrian Hunter
Cc: Waiman Long
Cc: David Ahern
Acked-and-tested-by: David Ahern
---
tools/perf/util/dso.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 45be944..ca8d8d5 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -45,13 +45,13 @@ int dso__read_binary_type_filename(const struct dso *dso,
case DSO_BINARY_TYPE__DEBUGLINK: {
char *debuglink;
- strncpy(filename, dso->long_name, size);
- debuglink = filename + dso->long_name_len;
+ len = __symbol__join_symfs(filename, size, dso->long_name);
+ debuglink = filename + len;
while (debuglink != filename && *debuglink != '/')
debuglink--;
if (*debuglink == '/')
debuglink++;
- ret = filename__read_debuglink(dso->long_name, debuglink,
+ ret = filename__read_debuglink(filename, debuglink,
size - (debuglink - filename));
}
break;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 0/6] Per-user clock constraints
On 01/27/2015 01:55 AM, Stephen Boyd wrote: > On 01/23/15 03:03, Tomeu Vizoso wrote: >> Hi, >> >> in this v13 I have: >> >> * added the latest R-b tags from Stephen, >> >> * split some lines that went over the 80-char limit, >> >> * made explicit in the docs that the range limits are inclusive, and >> >> * removed an ifdef in clkdev.c by adding a dev_id param to >> __of_clk_get_by_name. >> > > I think this patch series is ready to go except for the last one? Do you > plan on polishing that one some more? Not in time for 3.20, I'm afraid. Want to spin first each of my other series, then I will go back to it. Regards, Tomeu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpuidle/powernv: Read target_residency value of idle states from DT if available
On Tue, 2015-01-27 at 09:32 +0530, Preeti U Murthy wrote:
> On 01/23/2015 10:29 AM, Michael Ellerman wrote:
> > On Tue, 2015-20-01 at 11:26:49 UTC, Preeti U Murthy wrote:
> >> @@ -177,34 +178,39 @@ static int powernv_add_idle_states(void)
> >
> >>for (i = 0; i < dt_idle_states; i++) {
> >>
> >>flags = be32_to_cpu(idle_state_flags[i]);
> >> -
> >> - /* Cpuidle accepts exit_latency in us and we estimate
> >> - * target residency to be 10x exit_latency
> >> + /*
> >> + * Cpuidle accepts exit_latency and target_residency in us.
> >> + * Use default target_residency values if f/w does not expose
> >> it.
> >> */
> >> - latency_ns = be32_to_cpu(idle_state_latency[i]);
> >>if (flags & OPAL_PM_NAP_ENABLED) {
> >>/* Add NAP state */
> >>strcpy(powernv_states[nr_idle_states].name, "Nap");
> >>strcpy(powernv_states[nr_idle_states].desc, "Nap");
> >>powernv_states[nr_idle_states].flags = 0;
> >> - powernv_states[nr_idle_states].exit_latency =
> >> - ((unsigned int)latency_ns) / 1000;
> >> - powernv_states[nr_idle_states].target_residency =
> >> - ((unsigned int)latency_ns / 100);
> >> + powernv_states[nr_idle_states].target_residency = 100;
> >>powernv_states[nr_idle_states].enter = _loop;
> >> - nr_idle_states++;
> >
> > That looks wrong? Or do you mean to do that?
>
> If you are pointing at the lines that remove increment of
> nr_idle_states, it has to be done so towards the end of the iteration
> because we are yet to populate the exit_latency and target_residency
> outside of these conditions using this index.
Oh OK I think I get it, it's not clear at all.
The resulting code is:
for (i = 0; i < dt_idle_states; i++) {
flags = be32_to_cpu(idle_state_flags[i]);
/*
* Cpuidle accepts exit_latency and target_residency in us.
* Use default target_residency values if f/w does not expose
it.
*/
if (flags & OPAL_PM_NAP_ENABLED) {
/* Add NAP state */
strcpy(powernv_states[nr_idle_states].name, "Nap");
strcpy(powernv_states[nr_idle_states].desc, "Nap");
powernv_states[nr_idle_states].flags = 0;
powernv_states[nr_idle_states].target_residency = 100;
powernv_states[nr_idle_states].enter = _loop;
}
if (flags & OPAL_PM_SLEEP_ENABLED ||
flags & OPAL_PM_SLEEP_ENABLED_ER1) {
/* Add FASTSLEEP state */
strcpy(powernv_states[nr_idle_states].name,
"FastSleep");
strcpy(powernv_states[nr_idle_states].desc,
"FastSleep");
powernv_states[nr_idle_states].flags =
CPUIDLE_FLAG_TIMER_STOP;
powernv_states[nr_idle_states].target_residency =
30;
powernv_states[nr_idle_states].enter = _loop;
}
powernv_states[nr_idle_states].exit_latency =
((unsigned int)latency_ns[i]) / 1000;
if (!rc) {
powernv_states[nr_idle_states].target_residency =
((unsigned int)residency_ns[i]) / 1000;
}
nr_idle_states++;
}
Which looks like you could potentially overwrite the first set of values, "Nap"
with "FastSleep". But I think what you're going to tell me is that flags can
never satisfy both conditions, so we will only ever execute either the "Nap"
case OR the "FastSleep".
If so please change the code to make that obvious, ie. by using else if.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC 2/3] ftrace: introduce nohotpatch function attribute
On Mon, Jan 26, 2015 at 09:37:01AM -0500, Steven Rostedt wrote: > On Mon, 26 Jan 2015 13:54:53 +0100 > Heiko Carstens wrote: > > s390 will use the hotpatch attribute for function tracing, therefore > > introduce a nohotpatch define, depending on CC_USING_HOTPATCH, and add it > > to the existing notrace define. > > Are the two mutually exclusive? That is, can you have -pg and hotpatch > together? Reason why I ask is, if you have either -pg or hotpatch, then > we only need "no_instrument_function" or "hotpatch" in the notrace > define, not both. But I could be wrong. While the kernel may use only profiling or hotpatch at the same time, Gcc is able to generate both for the same function. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] posix_acl: fix reference leaks in posix_acl_create
get_acl gets a reference which we must release in the error cases.
Signed-off-by: Omar Sandoval
---
fs/posix_acl.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 0855f77..f8f3cc2 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -555,28 +555,31 @@ posix_acl_create(struct inode *dir, umode_t *mode,
p = get_acl(dir, ACL_TYPE_DEFAULT);
if (IS_ERR(p)) {
if (p == ERR_PTR(-EOPNOTSUPP))
goto apply_umask;
return PTR_ERR(p);
}
if (!p)
goto apply_umask;
*acl = posix_acl_clone(p, GFP_NOFS);
- if (!*acl)
+ if (!*acl) {
+ posix_acl_release(p);
return -ENOMEM;
+ }
ret = posix_acl_create_masq(*acl, mode);
if (ret < 0) {
posix_acl_release(*acl);
+ posix_acl_release(p);
return -ENOMEM;
}
if (ret == 0) {
posix_acl_release(*acl);
*acl = NULL;
}
if (!S_ISDIR(*mode)) {
posix_acl_release(p);
*default_acl = NULL;
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 12/13] pm: at91: setup: remove the struct ramc_ids .data at91_xxx_standby members
Because the at91_xxx_standby function is removed,
remove the struct ramc_ids .data members code.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/setup.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 4c18428..b8dba9f 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -362,10 +362,10 @@ void __init at91_ioremap_matrix(u32 base_addr)
}
static struct of_device_id ramc_ids[] = {
- { .compatible = "atmel,at91rm9200-sdramc", .data = at91rm9200_standby },
- { .compatible = "atmel,at91sam9260-sdramc", .data =
at91sam9_sdram_standby },
- { .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby },
- { .compatible = "atmel,sama5d3-ddramc", .data = at91_ddr_standby },
+ { .compatible = "atmel,at91rm9200-sdramc" },
+ { .compatible = "atmel,at91sam9260-sdramc" },
+ { .compatible = "atmel,at91sam9g45-ddramc" },
+ { .compatible = "atmel,sama5d3-ddramc" },
{ /*sentinel*/ }
};
@@ -374,28 +374,17 @@ static void at91_dt_ramc(void)
struct device_node *np;
const struct of_device_id *of_id;
int idx = 0;
- const void *standby = NULL;
for_each_matching_node_and_match(np, ramc_ids, _id) {
at91_ramc_base[idx] = of_iomap(np, 0);
if (!at91_ramc_base[idx])
panic(pr_fmt("unable to map ramc[%d] cpu registers\n"),
idx);
- if (!standby)
- standby = of_id->data;
-
idx++;
}
if (!idx)
panic(pr_fmt("unable to find compatible ram controller node in
dtb\n"));
-
- if (!standby) {
- pr_warn("ramc no standby function available\n");
- return;
- }
-
- at91_pm_set_standby(standby);
}
void __init at91_dt_initialize(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 13/13] pm: at91: amend the pm_suspend entry for at91_cpuidle_device
Because the at91_xxx_standby() function is substitued by the at91_pm_suspend(),
the pm_suspend entry for at91_cpuidle_device changes as well.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index ab1a4d6..faa5d30 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -40,8 +40,6 @@ static struct {
int memctrl;
} at91_pm_data;
-static void (*at91_pm_standby)(void);
-
static int at91_pm_valid_state(suspend_state_t state)
{
switch (state) {
@@ -214,12 +212,15 @@ static struct platform_device at91_cpuidle_device = {
.name = "cpuidle-at91",
};
-void at91_pm_set_standby(void (*at91_standby)(void))
+static void at91_cpuidle_suspend(void)
{
- if (at91_standby) {
- at91_cpuidle_device.dev.platform_data = at91_standby;
- at91_pm_standby = at91_standby;
- }
+ at91_pm_suspend(PM_SUSPEND_STANDBY);
+}
+
+static void at91_cpuidle_set_suspend(void (*at91_suspend)(void))
+{
+ if (at91_suspend)
+ at91_cpuidle_device.dev.platform_data = at91_suspend;
}
static void __init at91_pm_sram_init(void)
@@ -270,6 +271,8 @@ static void __init at91_pm_init(void)
{
at91_pm_sram_init();
+ at91_cpuidle_set_suspend(at91_cpuidle_suspend);
+
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(_cpuidle_device);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] ion:change ion_cma_allocate return error value
This patch change the error return value from -1 to -ENOMEM,
so that userspace can get the correct errno, otherwise,
-1 will be -EPERM, userspace will print permission deny for allocation
failure.
Signed-off-by: Yalin Wang
---
drivers/staging/android/ion/ion_cma_heap.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index f4211f1..55bcaec2 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -24,8 +24,6 @@
#include "ion.h"
#include "ion_priv.h"
-#define ION_CMA_ALLOCATE_FAILED -1
-
struct ion_cma_heap {
struct ion_heap heap;
struct device *dev;
@@ -59,7 +57,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
ion_buffer *buffer,
info = kzalloc(sizeof(struct ion_cma_buffer_info), GFP_KERNEL);
if (!info)
- return ION_CMA_ALLOCATE_FAILED;
+ return -ENOMEM;
info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
GFP_HIGHUSER | __GFP_ZERO);
@@ -87,7 +85,7 @@ free_mem:
dma_free_coherent(dev, len, info->cpu_addr, info->handle);
err:
kfree(info);
- return ION_CMA_ALLOCATE_FAILED;
+ return -ENOMEM;
}
static void ion_cma_free(struct ion_buffer *buffer)
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 11/13] pm: at91: remove the at91_xxx_standby() function definitions in the pm.h
Because the the suspend to standby mode uses the sram function,
these functions will not used, remove the redundant code.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.h | 97 ---
1 file changed, 97 deletions(-)
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 5bc9c33..158575e 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -12,7 +12,6 @@
#define __ARCH_ARM_MACH_AT91_PM
#include
-
#include
#defineAT91_PM_MEMCTRL_MASK0x0f
@@ -22,100 +21,4 @@
#defineAT91_PM_SLOW_CLOCK 0x01
-#ifdef CONFIG_PM
-extern void at91_pm_set_standby(void (*at91_standby)(void));
-#else
-static inline void at91_pm_set_standby(void (*at91_standby)(void)) { }
-#endif
-
-/*
- * The AT91RM9200 goes into self-refresh mode with this command, and will
- * terminate self-refresh automatically on the next SDRAM access.
- *
- * Self-refresh mode is exited as soon as a memory access is made, but we don't
- * know for sure when that happens. However, we need to restore the low-power
- * mode if it was enabled before going idle. Restoring low-power mode while
- * still in self-refresh is "not recommended", but seems to work.
- */
-
-static inline void at91rm9200_standby(void)
-{
- u32 lpr = at91_ramc_read(0, AT91RM9200_SDRAMC_LPR);
-
- asm volatile(
- "b1f\n\t"
- ".align5\n\t"
- "1: mcrp15, 0, %0, c7, c10, 4\n\t"
- "str%0, [%1, %2]\n\t"
- "str%3, [%1, %4]\n\t"
- "mcrp15, 0, %0, c7, c0, 4\n\t"
- "str%5, [%1, %2]"
- :
- : "r" (0), "r" (AT91_BASE_SYS), "r" (AT91RM9200_SDRAMC_LPR),
- "r" (1), "r" (AT91RM9200_SDRAMC_SRR),
- "r" (lpr));
-}
-
-/* We manage both DDRAM/SDRAM controllers, we need more than one value to
- * remember.
- */
-static inline void at91_ddr_standby(void)
-{
- /* Those two values allow us to delay self-refresh activation
-* to the maximum. */
- u32 lpr0, lpr1 = 0;
- u32 saved_lpr0, saved_lpr1 = 0;
-
- if (at91_ramc_base[1]) {
- saved_lpr1 = at91_ramc_read(1, AT91_DDRSDRC_LPR);
- lpr1 = saved_lpr1 & ~AT91_DDRSDRC_LPCB;
- lpr1 |= AT91_DDRSDRC_LPCB_SELF_REFRESH;
- }
-
- saved_lpr0 = at91_ramc_read(0, AT91_DDRSDRC_LPR);
- lpr0 = saved_lpr0 & ~AT91_DDRSDRC_LPCB;
- lpr0 |= AT91_DDRSDRC_LPCB_SELF_REFRESH;
-
- /* self-refresh mode now */
- at91_ramc_write(0, AT91_DDRSDRC_LPR, lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_DDRSDRC_LPR, lpr1);
-
- cpu_do_idle();
-
- at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
-}
-
-/* We manage both DDRAM/SDRAM controllers, we need more than one value to
- * remember.
- */
-static inline void at91sam9_sdram_standby(void)
-{
- u32 lpr0, lpr1 = 0;
- u32 saved_lpr0, saved_lpr1 = 0;
-
- if (at91_ramc_base[1]) {
- saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
- lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
- lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
- }
-
- saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
- lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
- lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
-
- /* self-refresh mode now */
- at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
-
- cpu_do_idle();
-
- at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
-}
-
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 10/13] pm: at91: rename function name: at91_slow_clock()-->at91_pm_suspend_sram_fn
As the file name's renaming, rename the file name at91_slow_clock()-->
at91_pm_suspend_sram_fn, rename the function handler's name at the same time.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.c | 27 +--
arch/arm/mach-at91/pm_suspend.S | 24 ++--
2 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index d967c31..ab1a4d6 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -129,13 +129,12 @@ int at91_suspend_entering_slow_clock(void)
}
EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
-
-static void (*slow_clock)(void __iomem *pmc, void __iomem *ramc0,
+static void (*at91_suspend_sram_fn)(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-extern void at91_slow_clock(void __iomem *pmc, void __iomem *ramc0,
+extern void at91_pm_suspend_in_sram(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-extern u32 at91_slow_clock_sz;
+extern u32 at91_pm_suspend_in_sram_sz;
static void at91_pm_suspend(suspend_state_t state)
{
@@ -144,8 +143,8 @@ static void at91_pm_suspend(suspend_state_t state)
pm_data |= (state == PM_SUSPEND_MEM) ?
AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
- slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1], pm_data);
+ at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],
+ at91_ramc_base[1], pm_data);
}
static int at91_pm_enter(suspend_state_t state)
@@ -249,17 +248,19 @@ static void __init at91_pm_sram_init(void)
goto put_node;
}
- sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
+ sram_base = gen_pool_alloc(sram_pool, at91_pm_suspend_in_sram_sz);
if (!sram_base) {
- pr_warn("%s: unable to alloc ocram!\n", __func__);
+ pr_warn("%s: unable to alloc sram!\n", __func__);
goto put_node;
}
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
- slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+ at91_suspend_sram_fn = __arm_ioremap_exec(sram_pbase,
+ at91_pm_suspend_in_sram_sz, false);
- /* Copy the slow_clock handler to SRAM */
- memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
+ /* Copy the pm suspend handler to SRAM */
+ memcpy(at91_suspend_sram_fn,
+ at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
put_node:
of_node_put(node);
@@ -269,12 +270,10 @@ static void __init at91_pm_init(void)
{
at91_pm_sram_init();
- pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
-
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(_cpuidle_device);
- if (slow_clock)
+ if (at91_suspend_sram_fn)
suspend_set_ops(_pm_ops);
else
pr_info("AT91: PM : Not supported, due to no sram allocated\n");
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 8edbad0..122a3f1 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -55,23 +55,19 @@ mode.reqr6
.text
-/* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
+/*
+ * void at91_pm_suspend_in_sram(void __iomem *pmc, void __iomem *sdramc,
* void __iomem *ramc1, int memctrl)
+ * @input param:
+ * @r0: the base address of AT91_PMC
+ * @r1: the base address of SDRAM Controller (SDRAM, DDRSDR, or AT91_SYS)
+ * @r2: the base address of second SDRAM Controller or 0 if not present
+ * @r3: the pm information
*/
-ENTRY(at91_slow_clock)
+ENTRY(at91_pm_suspend_in_sram)
/* Save registers on stack */
stmfd sp!, {r4 - r12, lr}
- /*
-* Register usage:
-* R0 = Base address of AT91_PMC
-* R1 = Base address of RAM Controller (SDRAM, DDRSDR, or AT91_SYS)
-* R2 = Base address of second RAM Controller or 0 if not present
-* R3 = Memory controller
-* R4 = temporary register
-* R5 = temporary register
-*/
-
/* Drain write buffer */
mov tmp1, #0
mcr p15, 0, tmp1, c7, c10, 4
@@ -277,5 +273,5 @@ ram_restored:
.saved_sam9_mdr1:
.word 0
-ENTRY(at91_slow_clock_sz)
- .word .-at91_slow_clock
+ENTRY(at91_pm_suspend_in_sram_sz)
+ .word .-at91_pm_suspend_in_sram
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 09/13] pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S
Because the sram function is used for the suspend to standby mode as well,
more than suspend to memory, so renaming is more elegant.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/Makefile |2 +-
arch/arm/mach-at91/pm_slowclock.S | 281 -
arch/arm/mach-at91/pm_suspend.S | 281 +
3 files changed, 282 insertions(+), 282 deletions(-)
delete mode 100644 arch/arm/mach-at91/pm_slowclock.S
create mode 100644 arch/arm/mach-at91/pm_suspend.S
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 13dd3e6..aba208f 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -27,7 +27,7 @@ obj-$(CONFIG_SOC_SAMA5) += board-dt-sama5.o
# Power Management
obj-$(CONFIG_PM) += pm.o
-obj-$(CONFIG_PM) += pm_slowclock.o
+obj-$(CONFIG_PM) += pm_suspend.o
ifeq ($(CONFIG_PM_DEBUG),y)
CFLAGS_pm.o += -DDEBUG
diff --git a/arch/arm/mach-at91/pm_slowclock.S
b/arch/arm/mach-at91/pm_slowclock.S
deleted file mode 100644
index f56d114..000
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * arch/arm/mach-at91/pm_slow_clock.S
- *
- * Copyright (C) 2006 Savin Zlobec
- *
- * AT91SAM9 support:
- * Copyright (C) 2007 Anti Sullin
-#include
-#include
-#include
-
-#include "pm.h"
-
-pmc.reqr0
-sdramc .reqr1
-ramc1 .reqr2
-memctrl.reqr3
-tmp1 .reqr4
-tmp2 .reqr5
-mode .reqr6
-
-/*
- * Wait until master clock is ready (after switching master clock source)
- */
- .macro wait_mckrdy
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_MCKRDY
- beq 1b
- .endm
-
-/*
- * Wait until master oscillator has stabilized.
- */
- .macro wait_moscrdy
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_MOSCS
- beq 1b
- .endm
-
-/*
- * Wait until PLLA has locked.
- */
- .macro wait_pllalock
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_LOCKA
- beq 1b
- .endm
-
- .text
-
-/* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
- * void __iomem *ramc1, int memctrl)
- */
-ENTRY(at91_slow_clock)
- /* Save registers on stack */
- stmfd sp!, {r4 - r12, lr}
-
- /*
-* Register usage:
-* R0 = Base address of AT91_PMC
-* R1 = Base address of RAM Controller (SDRAM, DDRSDR, or AT91_SYS)
-* R2 = Base address of second RAM Controller or 0 if not present
-* R3 = Memory controller
-* R4 = temporary register
-* R5 = temporary register
-*/
-
- /* Drain write buffer */
- mov tmp1, #0
- mcr p15, 0, tmp1, c7, c10, 4
-
- mov tmp1, memctrl
- mov tmp2, tmp1, lsr#AT91_PM_MODE_OFFSET
- and mode, tmp2, #AT91_PM_MODE_MASK
-
- mov tmp1, memctrl
- and memctrl, tmp1, #AT91_PM_MEMCTRL_MASK
-
- cmp memctrl, #AT91_MEMCTRL_MC
- bne ddr_sr_enable
-
- /*
-* at91rm9200 Memory controller
-*/
- /* Put SDRAM in self-refresh mode */
- mov tmp1, #1
- str tmp1, [sdramc, #AT91RM9200_SDRAMC_SRR]
- b sdr_sr_done
-
- /*
-* DDRSDR Memory controller
-*/
-ddr_sr_enable:
- cmp memctrl, #AT91_MEMCTRL_DDRSDR
- bne sdr_sr_enable
-
- /* LPDDR1 --> force DDR2 mode during self-refresh */
- ldr tmp1, [sdramc, #AT91_DDRSDRC_MDR]
- str tmp1, .saved_sam9_mdr
- bic tmp1, tmp1, #~AT91_DDRSDRC_MD
- cmp tmp1, #AT91_DDRSDRC_MD_LOW_POWER_DDR
- ldreq tmp1, [sdramc, #AT91_DDRSDRC_MDR]
- biceq tmp1, tmp1, #AT91_DDRSDRC_MD
- orreq tmp1, tmp1, #AT91_DDRSDRC_MD_DDR2
- streq tmp1, [sdramc, #AT91_DDRSDRC_MDR]
-
- /* prepare for DDRAM self-refresh mode */
- ldr tmp1, [sdramc, #AT91_DDRSDRC_LPR]
- str tmp1, .saved_sam9_lpr
- bic tmp1, #AT91_DDRSDRC_LPCB
- orr tmp1, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-
- /* figure out if we use the second ram controller */
- cmp ramc1, #0
- beq ddr_no_2nd_ctrl
-
- ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR]
- str tmp2, .saved_sam9_mdr1
- bic tmp2, tmp2, #~AT91_DDRSDRC_MD
- cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR
- ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR]
- biceq tmp2, tmp2, #AT91_DDRSDRC_MD
- orreq tmp2, tmp2, #AT91_DDRSDRC_MD_DDR2
- streq tmp2, [ramc1, #AT91_DDRSDRC_MDR]
-
- ldr tmp2, [ramc1, #AT91_DDRSDRC_LPR]
- str tmp2, .saved_sam9_lpr1
- bic tmp2, #AT91_DDRSDRC_LPCB
- orr tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-
- /* Enable DDRAM self-refresh mode */
- str tmp2, [ramc1,
[PATCH v3 08/13] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
To simply the PM code, the suspend to standby mode uses the same sram function
as the suspend to memory mode, running in the internal SRAM,
instead of the respective code for each mode.
But for the suspend to standby mode, the master clock doesn't
switch to the slow clock, and the main oscillator doesn't
turn off as well.
Signed-off-by: Wenyou Yang
---
arch/arm/mach-at91/pm.c | 87 +
arch/arm/mach-at91/pm.h |7 +++
arch/arm/mach-at91/pm_slowclock.S | 18
3 files changed, 65 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 0377c0d..d967c31 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -71,7 +71,7 @@ static int at91_pm_begin(suspend_state_t state)
* Verify that all the clocks are correct before entering
* slow-clock mode.
*/
-static int at91_pm_verify_clocks(void)
+static int at91_pm_verify_clocks(suspend_state_t state)
{
unsigned long scsr;
int i;
@@ -137,62 +137,55 @@ extern void at91_slow_clock(void __iomem *pmc, void
__iomem *ramc0,
void __iomem *ramc1, int memctrl);
extern u32 at91_slow_clock_sz;
+static void at91_pm_suspend(suspend_state_t state)
+{
+ unsigned int pm_data = at91_pm_data.memctrl;
+
+ pm_data |= (state == PM_SUSPEND_MEM) ?
+ AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
+
+ slow_clock(at91_pmc_base, at91_ramc_base[0],
+ at91_ramc_base[1], pm_data);
+}
+
static int at91_pm_enter(suspend_state_t state)
{
at91_pinctrl_gpio_suspend();
switch (state) {
+ /*
+* Suspend-to-RAM is like STANDBY plus slow clock mode, so
+* drivers must suspend more deeply, the master clock switches
+* to the clk32k and turns off the main oscillator
+*/
+ case PM_SUSPEND_MEM:
/*
-* Suspend-to-RAM is like STANDBY plus slow clock mode, so
-* drivers must suspend more deeply: only the master clock
-* controller may be using the main oscillator.
+* Ensure that clocks are in a valid state.
*/
- case PM_SUSPEND_MEM:
- /*
-* Ensure that clocks are in a valid state.
-*/
- if (!at91_pm_verify_clocks())
- goto error;
-
- /*
-* Enter slow clock mode by switching over to clk32k and
-* turning off the main oscillator; reverse on wakeup.
-*/
- if (slow_clock) {
- slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1],
- at91_pm_data.memctrl);
- break;
- } else {
- pr_info("AT91: PM - no slow clock mode enabled
...\n");
- /* FALLTHROUGH leaving master clock alone */
- }
+ if (!at91_pm_verify_clocks(state))
+ goto error;
- /*
-* STANDBY mode has *all* drivers suspended; ignores irqs not
-* marked as 'wakeup' event sources; and reduces DRAM power.
-* But otherwise it's identical to PM_SUSPEND_ON: cpu idle, and
-* nothing fancy done with main or cpu clocks.
-*/
- case PM_SUSPEND_STANDBY:
- /*
-* NOTE: the Wait-for-Interrupt instruction needs to be
-* in icache so no SDRAM accesses are needed until the
-* wakeup IRQ occurs and self-refresh is terminated.
-* For ARM 926 based chips, this requirement is weaker
-* as at91sam9 can access a RAM in self-refresh mode.
-*/
- if (at91_pm_standby)
- at91_pm_standby();
- break;
+ at91_pm_suspend(state);
- case PM_SUSPEND_ON:
- cpu_do_idle();
- break;
+ break;
- default:
- pr_debug("AT91: PM - bogus suspend state %d\n", state);
- goto error;
+ /*
+* STANDBY mode has *all* drivers suspended; ignores irqs not
+* marked as 'wakeup' event sources; and reduces DRAM power.
+* But otherwise it's identical to PM_SUSPEND_ON: cpu idle, and
+* nothing fancy done with main or cpu clocks.
+*/
+ case PM_SUSPEND_STANDBY:
+ at91_pm_suspend(state);
+ break;
+
+ case
[PATCH v3 07/13] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK
The slow clock always exists, for the suspend to memory mode,
the master clock always switch to the slow clock.
To simplify the PM config, remove this config item, remove
the definition code as well.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/Kconfig | 13 -
arch/arm/mach-at91/Makefile |2 +-
arch/arm/mach-at91/pm.c |7 ---
3 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index cbaf0c8..0af6744 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -160,19 +160,6 @@ endif # SOC_SAM_V4_V5
comment "AT91 Feature Selections"
-config AT91_SLOW_CLOCK
- bool "Suspend-to-RAM disables main oscillator"
- depends on SUSPEND
- help
- Select this if you want Suspend-to-RAM to save the most power
- possible (without powering off the CPU) by disabling the PLLs
- and main oscillator so that only the 32 KiHz clock is available.
-
- When only that slow-clock is available, some peripherals lose
- functionality. Many can't issue wakeup events unless faster
- clocks are available. Some lose their operating state and
- need to be completely re-initialized.
-
config AT91_TIMER_HZ
int "Kernel HZ (jiffies per second)"
range 32 1024
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 8ef7d9a..13dd3e6 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -27,7 +27,7 @@ obj-$(CONFIG_SOC_SAMA5) += board-dt-sama5.o
# Power Management
obj-$(CONFIG_PM) += pm.o
-obj-$(CONFIG_AT91_SLOW_CLOCK) += pm_slowclock.o
+obj-$(CONFIG_PM) += pm_slowclock.o
ifeq ($(CONFIG_PM_DEBUG),y)
CFLAGS_pm.o += -DDEBUG
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 6b08098..0377c0d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -133,11 +133,9 @@ EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
static void (*slow_clock)(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-#ifdef CONFIG_AT91_SLOW_CLOCK
extern void at91_slow_clock(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
extern u32 at91_slow_clock_sz;
-#endif
static int at91_pm_enter(suspend_state_t state)
{
@@ -232,7 +230,6 @@ void at91_pm_set_standby(void (*at91_standby)(void))
}
}
-#ifdef CONFIG_AT91_SLOW_CLOCK
static void __init at91_pm_sram_init(void)
{
struct gen_pool *sram_pool;
@@ -274,14 +271,10 @@ static void __init at91_pm_sram_init(void)
put_node:
of_node_put(node);
}
-#endif
-
static void __init at91_pm_init(void)
{
-#ifdef CONFIG_AT91_SLOW_CLOCK
at91_pm_sram_init();
-#endif
pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
mode)" : ""));
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/13] ARM: at91: move select SRAM to ARCH_AT91
Because the CONFIG_AT91_SLOW_CLOCK will be removed to simply the PM config, so move select SRAM. Signed-off-by: Wenyou Yang Acked-by: Alexandre Belloni --- arch/arm/mach-at91/Kconfig |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index c6956b8..cbaf0c8 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -24,6 +24,7 @@ config SOC_AT91SAM9 select GENERIC_CLOCKEVENTS select MEMORY select ATMEL_SDRAMC + select SRAM if PM config SOC_SAMA5 bool @@ -34,6 +35,7 @@ config SOC_SAMA5 select MEMORY select ATMEL_SDRAMC select PHYLIB if NETDEVICES + select SRAM if PM menu "Atmel AT91 System-on-Chip" @@ -91,6 +93,7 @@ config SOC_AT91RM9200 select CPU_ARM920T select GENERIC_CLOCKEVENTS select HAVE_AT91_USB_CLK + select SRAM if PM config SOC_AT91SAM9260 bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20" @@ -159,7 +162,6 @@ comment "AT91 Feature Selections" config AT91_SLOW_CLOCK bool "Suspend-to-RAM disables main oscillator" - select SRAM depends on SUSPEND help Select this if you want Suspend-to-RAM to save the most power -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 04/13] pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK
The SLOWDOWN_MASTER_CLOCK definition is not used, remove the redundant code. Signed-off-by: Wenyou Yang Acked-by: Alexandre Belloni --- arch/arm/mach-at91/pm_slowclock.S | 37 - 1 file changed, 37 deletions(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index 1155217..4e55665 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S @@ -11,20 +11,11 @@ * published by the Free Software Foundation. * */ - #include #include #include #include -/* - * When SLOWDOWN_MASTER_CLOCK is defined we will also slow down the Master - * clock during suspend by adjusting its prescalar and divisor. - * NOTE: This hasn't been shown to be stable on SAM9s; and on the RM9200 there - * are errata regarding adjusting the prescalar and divisor. - */ -#undef SLOWDOWN_MASTER_CLOCK - pmc.reqr0 sdramc .reqr1 ramc1 .reqr2 @@ -166,18 +157,6 @@ sdr_sr_done: wait_mckrdy -#ifdef SLOWDOWN_MASTER_CLOCK - /* -* Set the Master Clock PRES and MDIV fields. -* -* See AT91RM9200 errata #27 and #28 for details. -*/ - mov tmp1, #0 - str tmp1, [pmc, #AT91_PMC_MCKR] - - wait_mckrdy -#endif - /* Save PLLA setting and disable it */ ldr tmp1, [pmc, #AT91_CKGR_PLLAR] str tmp1, .saved_pllar @@ -213,22 +192,6 @@ sdr_sr_done: wait_pllalock 4: -#ifdef SLOWDOWN_MASTER_CLOCK - /* -* First set PRES if it was not 0, -* than set CSS and MDIV fields. -* -* See AT91RM9200 errata #27 and #28 for details. -*/ - ldr tmp1, .saved_mckr - tst tmp1, #AT91_PMC_PRES - beq 2f - and tmp1, tmp1, #AT91_PMC_PRES - str tmp1, [pmc, #AT91_PMC_MCKR] - - wait_mckrdy -#endif - /* * Restore master clock setting */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 03/13] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
From: Peter Rosin The DDRSDR controller fails miserably to put LPDDR1 memories in self-refresh. Force the controller to think it has DDR2 memories during the self-refresh period, as the DDR2 self-refresh spec is equivalent to LPDDR1, and is correctly implemented in the controller. Assume that the second controller has the same fault, but that is untested. Signed-off-by: Peter Rosin Acked-by: Nicolas Ferre --- arch/arm/mach-at91/pm_slowclock.S | 43 +++- include/soc/at91/at91sam9_ddrsdr.h |2 +- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index e2bfaf5..1155217 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S @@ -100,6 +100,16 @@ ddr_sr_enable: cmp memctrl, #AT91_MEMCTRL_DDRSDR bne sdr_sr_enable + /* LPDDR1 --> force DDR2 mode during self-refresh */ + ldr tmp1, [sdramc, #AT91_DDRSDRC_MDR] + str tmp1, .saved_sam9_mdr + bic tmp1, tmp1, #~AT91_DDRSDRC_MD + cmp tmp1, #AT91_DDRSDRC_MD_LOW_POWER_DDR + ldreq tmp1, [sdramc, #AT91_DDRSDRC_MDR] + biceq tmp1, tmp1, #AT91_DDRSDRC_MD + orreq tmp1, tmp1, #AT91_DDRSDRC_MD_DDR2 + streq tmp1, [sdramc, #AT91_DDRSDRC_MDR] + /* prepare for DDRAM self-refresh mode */ ldr tmp1, [sdramc, #AT91_DDRSDRC_LPR] str tmp1, .saved_sam9_lpr @@ -108,14 +118,26 @@ ddr_sr_enable: /* figure out if we use the second ram controller */ cmp ramc1, #0 - ldrne tmp2, [ramc1, #AT91_DDRSDRC_LPR] - strne tmp2, .saved_sam9_lpr1 - bicne tmp2, #AT91_DDRSDRC_LPCB - orrne tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH + beq ddr_no_2nd_ctrl + + ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR] + str tmp2, .saved_sam9_mdr1 + bic tmp2, tmp2, #~AT91_DDRSDRC_MD + cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR + ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR] + biceq tmp2, tmp2, #AT91_DDRSDRC_MD + orreq tmp2, tmp2, #AT91_DDRSDRC_MD_DDR2 + streq tmp2, [ramc1, #AT91_DDRSDRC_MDR] + + ldr tmp2, [ramc1, #AT91_DDRSDRC_LPR] + str tmp2, .saved_sam9_lpr1 + bic tmp2, #AT91_DDRSDRC_LPCB + orr tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH /* Enable DDRAM self-refresh mode */ + str tmp2, [ramc1, #AT91_DDRSDRC_LPR] +ddr_no_2nd_ctrl: str tmp1, [sdramc, #AT91_DDRSDRC_LPR] - strne tmp2, [ramc1, #AT91_DDRSDRC_LPR] b sdr_sr_done @@ -227,12 +249,17 @@ sdr_sr_done: */ cmp memctrl, #AT91_MEMCTRL_DDRSDR bne sdr_en_restore + /* Restore MDR in case of LPDDR1 */ + ldr tmp1, .saved_sam9_mdr + str tmp1, [sdramc, #AT91_DDRSDRC_MDR] /* Restore LPR on AT91 with DDRAM */ ldr tmp1, .saved_sam9_lpr str tmp1, [sdramc, #AT91_DDRSDRC_LPR] /* if we use the second ram controller */ cmp ramc1, #0 + ldrne tmp2, .saved_sam9_mdr1 + strne tmp2, [ramc1, #AT91_DDRSDRC_MDR] ldrne tmp2, .saved_sam9_lpr1 strne tmp2, [ramc1, #AT91_DDRSDRC_LPR] @@ -263,5 +290,11 @@ ram_restored: .saved_sam9_lpr1: .word 0 +.saved_sam9_mdr: + .word 0 + +.saved_sam9_mdr1: + .word 0 + ENTRY(at91_slow_clock_sz) .word .-at91_slow_clock diff --git a/include/soc/at91/at91sam9_ddrsdr.h b/include/soc/at91/at91sam9_ddrsdr.h index 0210797..dc10c52 100644 --- a/include/soc/at91/at91sam9_ddrsdr.h +++ b/include/soc/at91/at91sam9_ddrsdr.h @@ -92,7 +92,7 @@ #defineAT91_DDRSDRC_UPD_MR (3 << 20)/* Update load mode register and extended mode register */ #define AT91_DDRSDRC_MDR 0x20/* Memory Device Register */ -#defineAT91_DDRSDRC_MD (3 << 0)/* Memory Device Type */ +#defineAT91_DDRSDRC_MD (7 << 0)/* Memory Device Type */ #defineAT91_DDRSDRC_MD_SDR 0 #defineAT91_DDRSDRC_MD_LOW_POWER_SDR 1 #defineAT91_DDRSDRC_MD_LOW_POWER_DDR 3 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/13] pm: at91: move the copying the sram function to the sram initializationi phase
To decrease the suspend time, move the copying the sram function
to the sram initialization phase, instead of every time go to suspend.
In the meanwhile, if there is no sram allocated for PM, the PM is not supported.
Signed-off-by: Wenyou Yang
Acked-by: Alexandre Belloni
---
arch/arm/mach-at91/pm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 5dd4e41..6b08098 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -161,10 +161,6 @@ static int at91_pm_enter(suspend_state_t state)
* turning off the main oscillator; reverse on wakeup.
*/
if (slow_clock) {
-#ifdef CONFIG_AT91_SLOW_CLOCK
- /* copy slow_clock handler to SRAM, and call it
*/
- memcpy(slow_clock, at91_slow_clock,
at91_slow_clock_sz);
-#endif
slow_clock(at91_pmc_base, at91_ramc_base[0],
at91_ramc_base[1],
at91_pm_data.memctrl);
@@ -272,6 +268,9 @@ static void __init at91_pm_sram_init(void)
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+ /* Copy the slow_clock handler to SRAM */
+ memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
+
put_node:
of_node_put(node);
}
@@ -289,7 +288,10 @@ static void __init at91_pm_init(void)
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(_cpuidle_device);
- suspend_set_ops(_pm_ops);
+ if (slow_clock)
+ suspend_set_ops(_pm_ops);
+ else
+ pr_info("AT91: PM : Not supported, due to no sram allocated\n");
}
void __init at91_rm9200_pm_init(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BPF backend has landed in LLVM
llvm trunk now has BPF backend: https://twitter.com/llvmweekly/status/559076464973594625 It's the one used to build samples/bpf/*_kern.c examples. Compiler just emits extended BPF instructions. It's not aware whether they are used for tracing or networking, or how they're loaded into the kernel. the backend has 'experimental' status, meaning that it doesn't get configured by default and one needs to use --enable-experimental-targets=bpf to build it. todo list: - promote it from 'experimental' status by the time llvm 3.7 is released :) - write front-end for tracing via mcjit api llvm will be used as a library: parsing of some tracing language, codegen, loading of bpf via syscall will be done from one process - tighten accepted IR and improve error reporting (currently it can compile too much of C that kernel will later reject, so need to make strict) - test/fix what it emits on arm and other archs (all little endian should work as-is, big-endian might need some fixes) - support 32-bit subregisters If anyone has spare cycles to help out, it would be great. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 02/13] pm: at91: pm_slowclock: remove clocks which are already stopped when entering slow clock mode
From: Sylvain Rochet
Assume USB PLL and PLL B are already stopped before entering sleep mode,
print a warning if this isn't the case.
Removed PLL B from slow clock code, all drivers are supposed to properly
unprepare clocks.
Signed-off-by: Sylvain Rochet
---
arch/arm/mach-at91/pm.c | 12
arch/arm/mach-at91/pm_slowclock.S | 31 ---
2 files changed, 12 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 87c1fd8..5dd4e41 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -98,6 +98,18 @@ static int at91_pm_verify_clocks(void)
}
}
+ /* Drivers should have previously suspended USB PLL */
+ if (at91_pmc_read(AT91_CKGR_UCKR) & AT91_PMC_UPLLEN) {
+ pr_err("AT91: PM - Suspend-to-RAM with USB PLL running\n");
+ return 0;
+ }
+
+ /* Drivers should have previously suspended PLL B */
+ if (at91_pmc_read(AT91_PMC_SR) & AT91_PMC_LOCKB) {
+ pr_err("AT91: PM - Suspend-to-RAM with PLL B running\n");
+ return 0;
+ }
+
return 1;
}
diff --git a/arch/arm/mach-at91/pm_slowclock.S
b/arch/arm/mach-at91/pm_slowclock.S
index 50744e7..e2bfaf5 100644
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ b/arch/arm/mach-at91/pm_slowclock.S
@@ -59,15 +59,6 @@ tmp2 .reqr5
beq 1b
.endm
-/*
- * Wait until PLLB has locked.
- */
- .macro wait_pllblock
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_LOCKB
- beq 1b
- .endm
-
.text
/* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
@@ -173,13 +164,6 @@ sdr_sr_done:
orr tmp1, tmp1, #(1 << 29) /* bit 29 always set */
str tmp1, [pmc, #AT91_CKGR_PLLAR]
- /* Save PLLB setting and disable it */
- ldr tmp1, [pmc, #AT91_CKGR_PLLBR]
- str tmp1, .saved_pllbr
-
- mov tmp1, #AT91_PMC_PLLCOUNT
- str tmp1, [pmc, #AT91_CKGR_PLLBR]
-
/* Turn off the main oscillator */
ldr tmp1, [pmc, #AT91_CKGR_MOR]
bic tmp1, tmp1, #AT91_PMC_MOSCEN
@@ -195,18 +179,6 @@ sdr_sr_done:
wait_moscrdy
- /* Restore PLLB setting */
- ldr tmp1, .saved_pllbr
- str tmp1, [pmc, #AT91_CKGR_PLLBR]
-
- tst tmp1, #(AT91_PMC_MUL & 0xff)
- bne 1f
- tst tmp1, #(AT91_PMC_MUL & ~0xff)
- beq 2f
-1:
- wait_pllblock
-2:
-
/* Restore PLLA setting */
ldr tmp1, .saved_pllar
str tmp1, [pmc, #AT91_CKGR_PLLAR]
@@ -285,9 +257,6 @@ ram_restored:
.saved_pllar:
.word 0
-.saved_pllbr:
- .word 0
-
.saved_sam9_lpr:
.word 0
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 01/13] pm: at91: pm_slowclock: fix suspend/resume hang up in timeouts
From: Sylvain Rochet Removed timeout on XTAL, PLL lock and Master Clock Ready, hang if something went wrong instead of continuing in unknown condition. There is not much we can do if a PLL lock never ends, we are running in SRAM and we will not be able to connect back the sdram or ddram in order to be able to fire up a message or just panic. As a bonus, not decounting the timeout register in slow clock mode reduce cumulated suspend time and resume time from ~17ms to ~15ms. Signed-off-by: Sylvain Rochet --- arch/arm/mach-at91/pm_slowclock.S | 33 - 1 file changed, 4 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index 556151e..50744e7 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S @@ -25,11 +25,6 @@ */ #undef SLOWDOWN_MASTER_CLOCK -#define MCKRDY_TIMEOUT 1000 -#define MOSCRDY_TIMEOUT1000 -#define PLLALOCK_TIMEOUT 1000 -#define PLLBLOCK_TIMEOUT 1000 - pmc.reqr0 sdramc .reqr1 ramc1 .reqr2 @@ -41,56 +36,36 @@ tmp2.reqr5 * Wait until master clock is ready (after switching master clock source) */ .macro wait_mckrdy - mov tmp2, #MCKRDY_TIMEOUT -1: sub tmp2, tmp2, #1 - cmp tmp2, #0 - beq 2f - ldr tmp1, [pmc, #AT91_PMC_SR] +1: ldr tmp1, [pmc, #AT91_PMC_SR] tst tmp1, #AT91_PMC_MCKRDY beq 1b -2: .endm /* * Wait until master oscillator has stabilized. */ .macro wait_moscrdy - mov tmp2, #MOSCRDY_TIMEOUT -1: sub tmp2, tmp2, #1 - cmp tmp2, #0 - beq 2f - ldr tmp1, [pmc, #AT91_PMC_SR] +1: ldr tmp1, [pmc, #AT91_PMC_SR] tst tmp1, #AT91_PMC_MOSCS beq 1b -2: .endm /* * Wait until PLLA has locked. */ .macro wait_pllalock - mov tmp2, #PLLALOCK_TIMEOUT -1: sub tmp2, tmp2, #1 - cmp tmp2, #0 - beq 2f - ldr tmp1, [pmc, #AT91_PMC_SR] +1: ldr tmp1, [pmc, #AT91_PMC_SR] tst tmp1, #AT91_PMC_LOCKA beq 1b -2: .endm /* * Wait until PLLB has locked. */ .macro wait_pllblock - mov tmp2, #PLLBLOCK_TIMEOUT -1: sub tmp2, tmp2, #1 - cmp tmp2, #0 - beq 2f - ldr tmp1, [pmc, #AT91_PMC_SR] +1: ldr tmp1, [pmc, #AT91_PMC_SR] tst tmp1, #AT91_PMC_LOCKB beq 1b -2: .endm .text -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] rtmutex: enable deadlock detection in the ww_mutex_lock functions
According the ww-mutex-design.txt documentation, the ww_mutex_lock_interruptible and ww_mutex_lock functions should return -EDEADLK when faced with a deadlock. To do so, the flag detect_deadlock in the rt_mutex_slowlock calls should be enabled. This patch corrects potential deadlocks when running PREEMPT_RT with nouveau driver. Kernel v3.14-rt Signed-off-by: Gustavo Bittencourt --- kernel/locking/rtmutex.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 6c40660..3f6ef91 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1965,7 +1965,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ww_c might_sleep(); mutex_acquire(>base.dep_map, 0, 0,_RET_IP_); - ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(>base.lock, TASK_INTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(>base.dep_map, 1,_RET_IP_); else if (!ret && ww_ctx->acquired > 1) @@ -1984,7 +1984,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ww_ctx) mutex_acquire_nest(>base.dep_map, 0, 0, _ctx->dep_map, _RET_IP_); - ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, 0, ww_ctx); + ret = rt_mutex_slowlock(>base.lock, TASK_UNINTERRUPTIBLE, NULL, 1, ww_ctx); if (ret) mutex_release(>base.dep_map, 1,_RET_IP_); else if (!ret && ww_ctx->acquired > 1) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 00/13] AT91 pm cleanup for 3.20
Hi Nicolas, This version is rebased on the branch: at91-3.20-cleanup of the repository git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git It is purpose to clean up the PM code, includes the patches from Peter Rosin and Sylvain Rochet. Since verifying the USB clock and USB PLL disabling before suspending to memory, it aslo depends on the following patch serials from Sylvain: [PATCHv6 0/5] USB: gadget: atmel_usba_udc: Driver improvements [PATCHv7 0/6] USB: host: Atmel OHCI and EHCI drivers improvements Removes CONFIG_AT91_SLOW_CLOCK config item to simply the PM config, The suspend to standby mode uses the same sram function as the suspend to memory mode. Remove some unused code. Alexandr & Sylvain, Thank you very much for so many feedbacks. Changes in v2: - Rebase on the at91-3.20-cleanup branch - Recover the verify clock condition, only for suspend to memory. - Collect ACK from Alexandre - Add the macro for PM mode Changes in v3 - Sylvain splits the patch in two - Add handling if no sram allocated for PM - Retain the STANDBY and SUSPEND_MEM select in at91_pm_enter. Peter Rosin (1): pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories. Sylvain Rochet (2): pm: at91: pm_slowclock: fix suspend/resume hang up in timeouts pm: at91: pm_slowclock: remove clocks which are already stopped when entering slow clock mode Wenyou Yang (10): pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK pm: at91: move the copying the sram function to the sram initializationi phase ARM: at91: move select SRAM to ARCH_AT91 pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK pm: at91: the standby mode uses the same sram function as the suspend to memory mode pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S pm: at91: rename function name: at91_slow_clock()-->at91_pm_suspend_sram_fn pm: at91: remove the at91_xxx_standby() function definitions in the pm.h pm: at91: setup: remove the struct ramc_ids .data at91_xxx_standby members pm: at91: amend the pm_suspend entry for at91_cpuidle_device arch/arm/mach-at91/Kconfig | 17 +- arch/arm/mach-at91/Makefile|2 +- arch/arm/mach-at91/pm.c| 150 - arch/arm/mach-at91/pm.h| 100 +-- arch/arm/mach-at91/pm_slowclock.S | 323 arch/arm/mach-at91/pm_suspend.S| 277 +++ arch/arm/mach-at91/setup.c | 19 +-- include/soc/at91/at91sam9_ddrsdr.h |2 +- 8 files changed, 367 insertions(+), 523 deletions(-) delete mode 100644 arch/arm/mach-at91/pm_slowclock.S create mode 100644 arch/arm/mach-at91/pm_suspend.S -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: Fix sibling map with NumaChip
On NumaChip systems, the physical processor ID assignment wasn't accounting
for the number of nodes in AMD multi-module processors, giving an incorrect
sibling map:
$ cd /sys/devices/system/cpu/cpu29/topology
$ grep . *
core_id:5
core_siblings:,ff00
core_siblings_list:24-31
physical_package_id:3
thread_siblings:,3000
thread_siblings_list:28-29
After fixing:
core_id:5
core_siblings:,
core_siblings_list:16-31
physical_package_id:1
thread_siblings:,3000
thread_siblings_list:28-29
Candidate for stable.
Signed-off-by: Daniel J Blueman
---
arch/x86/kernel/apic/apic_numachip.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/apic/apic_numachip.c
b/arch/x86/kernel/apic/apic_numachip.c
index 19f893f..a59768b 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -180,11 +180,15 @@ static int __init numachip_probe(void)
static void fixup_cpu_id(struct cpuinfo_x86 *c, int node)
{
-
- if (c->phys_proc_id != node) {
- c->phys_proc_id = node;
- per_cpu(cpu_llc_id, smp_processor_id()) = node;
- }
+ u64 val;
+ u32 nodes;
+
+ per_cpu(cpu_llc_id, smp_processor_id()) = node;
+
+ /* Account for nodes per socket in multi-core-module processors */
+ rdmsrl(MSR_FAM10H_NODE_ID, val);
+ nodes = ((val >> 3) & 7) + 1;
+ c->phys_proc_id = node / nodes;
}
static int parse_oemn(struct acpi_table_header *table)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] dts: Documentation: Add documentation for Exynos7 SoC thermal bindings
Add documentation for exynos7 thermal bindings including compatible name and special clock properties. Signed-off-by: Abhilash Kesavan --- .../devicetree/bindings/thermal/exynos-thermal.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index 0f44932..695150a 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -12,6 +12,7 @@ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock) "samsung,exynos5440-tmu" + "samsung,exynos7-tmu" - interrupt-parent : The phandle for the interrupt controller - reg : Address range of the thermal registers. For soc's which has multiple instances of TMU and some registers are shared across all TMU's like @@ -32,10 +33,13 @@ - clocks : The main clocks for TMU device -- 1. operational clock for TMU channel -- 2. optional clock to access the shared registers of TMU channel + -- 3. optional special clock for functional operation - clock-names : Thermal system clock name -- "tmu_apbif" operational clock for current TMU channel -- "tmu_triminfo_apbif" clock to access the shared triminfo register for current TMU channel + -- "tmu_sclk" clock for functional operation of the current TMU + channel - vtmu-supply: This entry is optional and provides the regulator node supplying voltage to TMU. If needed this entry can be placed inside board/platform specific dts file. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC
Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).
This patch adds special clock support required only for Exynos7. It
also updates the "code_to_temp" prototype as Exynos7 has 9 bit
code-temp mapping.
Signed-off-by: Abhilash Kesavan
---
This patch set has been tested on linux next-20150123 with Eduardo's
thermal-next branch merged along with the arch-side exynos7 related
dts changes applied.
Changes since v3:
Addressed comments from Lukasz Majewski:
- Added more comments in the code setting the thresholds.
- Split the documentation out into another patch.
Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.
drivers/thermal/samsung/exynos_tmu.c | 204 --
drivers/thermal/samsung/exynos_tmu.h |1 +
2 files changed, 197 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 852e622..660ff69 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6 0x50
+#define EXYNOS7_THD_TEMP_FALL7_6 0x60
+#define EXYNOS7_TMU_REG_INTEN 0x110
+#define EXYNOS7_TMU_REG_INTPEND0x118
+#define EXYNOS7_TMU_REG_EMUL_CON 0x160
+
+#define EXYNOS7_TMU_TEMP_MASK 0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT 0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT 1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT 2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT 3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT 4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT 5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT 6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT 7
+#define EXYNOS7_EMUL_DATA_SHIFT7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
#define MCELSIUS 1000
/**
* struct exynos_tmu_data : A structure to hold the private data of the TMU
@@ -133,6 +153,7 @@
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
* @clk_sec: pointer to the clock structure for accessing the base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu special clk.
* @temp_error1: fused value of the first point trim.
* @temp_error2: fused value of the second point trim.
* @regulator: pointer to the TMU regulator structure.
@@ -152,8 +173,8 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
- struct clk *clk, *clk_sec;
- u8 temp_error1, temp_error2;
+ struct clk *clk, *clk_sec, *sclk;
+ u16 temp_error1, temp_error2;
struct regulator *regulator;
struct thermal_zone_device *tzd;
@@ -223,7 +244,7 @@ static int temp_to_code(struct exynos_tmu_data *data, u8
temp)
* Calculate a temperature value from a temperature code.
* The unit of the temperature is degree Celsius.
*/
-static int code_to_temp(struct exynos_tmu_data *data, u8 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
{
struct exynos_tmu_platform_data *pdata = data->pdata;
int temp;
@@ -513,6 +534,84 @@ static int exynos5440_tmu_initialize(struct
platform_device *pdev)
return ret;
}
+static int exynos7_tmu_initialize(struct platform_device *pdev)
+{
+ struct exynos_tmu_data *data = platform_get_drvdata(pdev);
+ struct
Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
On 2015/1/24 2:09, Arend van Spriel wrote: > On 01/23/15 16:29, Kalle Valo wrote: >> Arend van Spriel writes: >> >>> On 01/22/15 14:54, Sergei Shtylyov wrote: Hello. On 1/22/2015 4:49 PM, Kalle Valo wrote: >> > From 04d3fa673897ca4ccbea6c76836d0092dba2484a Mon Sep 17 00:00:00 2001 >> From: Zhonghui Fu >> Date: Tue, 20 Jan 2015 11:14:13 +0800 >> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation >> WiFi chip has 2 SDIO functions, and PM core will trigger >> twice suspend/resume operations for one WiFi chip to do >> the same things. This patch avoid this case. >> Acked-by: Arend van Spriel >> Acked-by: Sergei Shtylyov >> Acked-by: Kalle Valo >> Signed-off-by: Zhonghui Fu > I don't remember giving Acked-by to this (or for matter to anything for > a long time). What about Sergei or Arend? I haven't ACK'ed this patch either. >>> >>> I did ACK the initial patch and felt it still valid for this 'V2' patch. >> >> Ok, thanks. So the patch is good, Zhonghui just needs to remove the two >> acked-by lines. > > Indeed. I have removed the two acked-by lines and sent the new patch in another mail. Thanks, Zhonghui > > Regards, > Arend > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: MSI: Fix freeing of unallocated MSI
On 2015/1/27 3:10, Marc Zyngier wrote:
> While debugging an unrelated issue with the GICv3 ITS driver, the
> following trace triggered:
>
> WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1121
> irq_domain_free_irqs+0x160/0x17c()
> NULL pointer, cannot free irq
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW 3.19.0-rc6+ #3690
> Hardware name: FVP Base (DT)
> Call trace:
> [] dump_backtrace+0x0/0x13c
> [] show_stack+0x10/0x1c
> [] dump_stack+0x74/0x94
> [] warn_slowpath_common+0x9c/0xd4
> [] warn_slowpath_fmt+0x5c/0x80
> [] irq_domain_free_irqs+0x15c/0x17c
> [] msi_domain_free_irqs+0x58/0x74
> [] free_msi_irqs+0xb4/0x1c0
>
> // The msi_prepare callback fails here
>
> [] pci_enable_msix+0x25c/0x3d4
> [] pci_enable_msix_range+0x34/0x80
> [] vp_try_to_find_vqs+0xec/0x528
> [] vp_find_vqs+0x6c/0xa8
> [] init_vq+0x120/0x248
> [] virtblk_probe+0xb0/0x6bc
> [] virtio_dev_probe+0x17c/0x214
> [] driver_probe_device+0x7c/0x23c
> [] __driver_attach+0x98/0xa0
> [] bus_for_each_dev+0x60/0xb4
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x150/0x208
> [] driver_register+0x64/0x130
> [] register_virtio_driver+0x24/0x68
> [] init+0x70/0xac
> [] do_one_initcall+0x94/0x1d0
> [] kernel_init_freeable+0x144/0x1e4
> [] kernel_init+0xc/0xd8
> ---[ end trace f9ee562a77cc7bae ]---
>
> The ITS msi_prepare callback having failed, we end-up trying to
> free MSIs that have never been allocated. Oddly enough, the kernel
> is pretty upset about it.
>
> It turns out that this behaviour was expected before the MSI domain
> was introduced (and dealt with in arch_teardown_msi_irqs).
>
> The obvious fix is to detect this early enough and bail out.
>
> Signed-off-by: Marc Zyngier
> ---
> kernel/irq/msi.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
> index 3e18163..474de5c 100644
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -310,8 +310,15 @@ void msi_domain_free_irqs(struct irq_domain *domain,
> struct device *dev)
> struct msi_desc *desc;
>
> for_each_msi_entry(desc, dev) {
> - irq_domain_free_irqs(desc->irq, desc->nvec_used);
> - desc->irq = 0;
> + /*
> + * We might have failed to allocate an MSI early
> + * enough that there is no IRQ associated to this
> + * entry. If that's the case, don't do anything.
> + */
> + if (desc->irq) {
> + irq_domain_free_irqs(desc->irq, desc->nvec_used);
> + desc->irq = 0;
> + }
> }
> }
>
>
Review-by: Jiang Liu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/7] pm: at91: add achieve the mpddrc peripheral ID and the DDR clock ID support
Hi Mark,
Thank you for your review.
> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Monday, January 26, 2015 7:50 PM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; li...@arm.linux.org.uk; sylvain.roc...@finsecur.com;
> Vilchez,
> Patrice; linux-kernel@vger.kernel.org; alexandre.bell...@free-electrons.com;
> p...@axentia.se; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 6/7] pm: at91: add achieve the mpddrc peripheral ID and
> the
> DDR clock ID support
>
> On Mon, Jan 26, 2015 at 10:08:16AM +, Wenyou Yang wrote:
> > The patch achieves the mpddr controller peripheral ID and the DDR
> > clock ID from the dts file.
> >
> > They will be used in the future to disable the mpddr controller'c
> > clock the and DDR clock to decrease the power consumption during suspending.
> >
> > Signed-off-by: Wenyou Yang
> > ---
> > arch/arm/mach-at91/generic.h |2 ++
> > arch/arm/mach-at91/setup.c | 24
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/arch/arm/mach-at91/generic.h
> > b/arch/arm/mach-at91/generic.h index 41796bf..3c72a3e 100644
> > --- a/arch/arm/mach-at91/generic.h
> > +++ b/arch/arm/mach-at91/generic.h
> > @@ -47,6 +47,8 @@ void __init at91_sam9x5_pm_init(void) { } struct
> > at91_pm_struct {
> > unsigned long uhp_udp_mask;
> > int memctrl;
> > + u32 mpddrc_id[2];
> > + u32 ddrck_id;
> > };
> >
> > #endif /* _AT91_GENERIC_H */
> > diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> > index 7924663..a306f95 100644
> > --- a/arch/arm/mach-at91/setup.c
> > +++ b/arch/arm/mach-at91/setup.c
> > @@ -363,6 +363,27 @@ void __init at91_ioremap_matrix(u32 base_addr)
> > panic(pr_fmt("Impossible to ioremap at91_matrix_base\n")); }
> >
> > +static u32 at91_of_get_ddr_id(struct device_node *np, char *name) {
> > + struct of_phandle_args clkspec;
> > + u32 id;
> > + int index;
> > + int rc;
> > +
> > + index = of_property_match_string(np, "clock-names", name);
> > + rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
> );
> > + if (rc)
> > + return 0;
> > +
> > + rc = of_property_read_u32(clkspec.np, "reg", );
> > + if (rc)
> > + return 0;
> > +
> > + of_node_put(clkspec.np);
> > +
> > + return id;
> > +}
>
> This doesn't look right to me. This assumes the format of the clock provider
> node,
> which invalidates the point of having the abstraction in the first place.
>
> > +
> > struct at91_ramc_of_data {
> > u8 ramc_type;
> > };
> > @@ -400,6 +421,9 @@ static void at91_dt_ramc(void)
> > of_data = of_id->data;
> > at91_pm_data.memctrl = of_data->ramc_type;
> >
> > + at91_pm_data.mpddrc_id[idx] = at91_of_get_ddr_id(np, "mpddr");
> > + at91_pm_data.ddrck_id = at91_of_get_ddr_id(np, "ddrck");
> > +
>
> Why do you need these here?
>
> Surely the logic for poking any clocks should live in the relevant clock
> controller
> drivers?
Thank for your suggestion.
I thought that it is reasonable to get the DDR controller's peripheral id from
the DDR device node.
Anyway, let me think over how to do it.
>
> Mark.
Best Regards,
Wenyou Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] block: loop: introduce 'use_aio' sysfs file
On 1/25/15, Christoph Hellwig wrote: > On Tue, Jan 13, 2015 at 11:44:47PM +0800, Ming Lei wrote: >> So that users can control if kernel aio is used to submit I/O. > > Why do you want a sysfs flag for this instead of a flags in ->lo_flags > at setup time? That's how all other loop-related ABI flags work. The flag only effects performance or CPU/memory resource utilization, and I plan to change it as dio flag. On Tue, Jan 27, 2015 at 1:57 AM, Jeff Moyer wrote: > Ming Lei writes: > >> So that users can control if kernel aio is used to submit I/O. > > How would a user know to choose aio or, um, /not/ aio? At the very > least, documentation is required for this. I'd rather see the option > disappear completely, though. As the comment says in patch 4/4, using direct I/O can save memory/CPU a lot, and won't hurt throughput if I/O is from filesystem. Otherwise, user may choose to not use direct I/O for sake of throughput. Thanks, Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull mpe/linux.git powerpc-3.19-5 tag
Hi Linus, Please pull two powerpc fixes for 3.19: The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc: Linux 3.19-rc5 (2015-01-18 18:02:20 +1200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-3.19-5 for you to fetch changes up to 0eb13208aa16ca5517835ea8f3feef091a13b984: powerpc/powernv: Restore LPCR with LPCR_PECE1 cleared (2015-01-22 17:22:57 +1100) Laurent Dufour (1): powerpc/xmon: Fix another endiannes issue in RTAS call from xmon Shreyas B. Prabhu (1): powerpc/powernv: Restore LPCR with LPCR_PECE1 cleared arch/powerpc/platforms/powernv/setup.c | 2 +- arch/powerpc/xmon/xmon.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) signature.asc Description: This is a digitally signed message part
linux-next: manual merge of the clockevents tree with the arm tree
Hi Daniel,
Today's linux-next merge of the clockevents tree got a conflict in
drivers/clocksource/Kconfig between commit e074ff86e8b4 ("ARM: 8251/1:
clocksource: enable pxa_timer for SA-1100 platform") from the arm tree
and commit e4940cd76934 ("ARM: clocksource: add asm9260_timer driver")
from the clockevents tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/clocksource/Kconfig
index 6b6f1e4950df,4f2240c9c145..
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@@ -232,11 -236,13 +239,20 @@@ config CLKSRC_MIPS_GI
depends on MIPS_GIC
select CLKSRC_OF
+config CLKSRC_PXA
+ def_bool y if ARCH_PXA || ARCH_SA1100
+ select CLKSRC_OF if USE_OF
+ help
+This enables OST0 support available on PXA and SA-11x0
+platforms.
+
+ config ASM9260_TIMER
+ bool "Alphascale ASM9260 timer driver"
+ select CLKSRC_MMIO
+ select CLKSRC_OF
+ default y if MACH_ASM9260
+ help
+ This enables build of a clocksource and clockevent driver for
+ the 32-bit System Timer hardware available on a Alphascale ASM9260.
+
endmenu
pgpVhqZWx20jK.pgp
Description: OpenPGP digital signature
RE: [PATCH 4/7] ARM: at91: enable the L2 Cache controller
Hi Alexandre,
> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: Tuesday, January 27, 2015 6:37 AM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; li...@arm.linux.org.uk;
> linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; sylvain.roc...@finsecur.com; p...@axentia.se;
> Vilchez, Patrice
> Subject: Re: [PATCH 4/7] ARM: at91: enable the L2 Cache controller
>
> Hi Wenyou,
>
> This patch is not necessary, the only thing missing is the prefetch
> configuration
> and I will submit the correct DT snippet for 3.21.
I will drop this patch.
>
> On 26/01/2015 at 18:07:16 +0800, Wenyou Yang wrote :
> > Signed-off-by: Wenyou Yang
> > ---
> > arch/arm/mach-at91/board-dt-sama5.c | 53
> +++
> > 1 file changed, 53 insertions(+)
> >
> > diff --git a/arch/arm/mach-at91/board-dt-sama5.c
> > b/arch/arm/mach-at91/board-dt-sama5.c
> > index 86cffcd..ed6db28 100644
> > --- a/arch/arm/mach-at91/board-dt-sama5.c
> > +++ b/arch/arm/mach-at91/board-dt-sama5.c
> > @@ -17,17 +17,70 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "generic.h"
> >
> > +void __iomem *at91_l2cc_base;
> > +EXPORT_SYMBOL_GPL(at91_l2cc_base);
> > +
> > +#ifdef CONFIG_CACHE_L2X0
> > +static void __init at91_init_l2cache(void) {
> > + struct device_node *np;
> > + u32 reg;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
> > + if (!np)
> > + return;
> > +
> > + at91_l2cc_base = of_iomap(np, 0);
> > + if (!at91_l2cc_base)
> > + panic("unable to map l2cc cpu registers\n");
> > +
> > + of_node_put(np);
> > +
> > + /* Disable cache if it hasn't been done yet */
> > + if (readl_relaxed(at91_l2cc_base + L2X0_CTRL) & L2X0_CTRL_EN)
> > + writel_relaxed(~L2X0_CTRL_EN, at91_l2cc_base + L2X0_CTRL);
> > +
> > + /* Prefetch Control */
> > + reg = readl_relaxed(at91_l2cc_base + L310_PREFETCH_CTRL);
> > + reg &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
> > + reg |= 0x01;
> > + reg |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
> > + reg |= L310_PREFETCH_CTRL_PREFETCH_DROP;
> > + reg |= L310_PREFETCH_CTRL_DATA_PREFETCH;
> > + reg |= L310_PREFETCH_CTRL_INSTR_PREFETCH;
> > + reg |= L310_PREFETCH_CTRL_DBL_LINEFILL;
> > + writel_relaxed(reg, at91_l2cc_base + L310_PREFETCH_CTRL);
> > +
> > + /* Power Control */
> > + reg = readl_relaxed(at91_l2cc_base + L310_POWER_CTRL);
> > + reg |= L310_STNDBY_MODE_EN;
> > + reg |= L310_DYNAMIC_CLK_GATING_EN;
> > + writel_relaxed(reg, at91_l2cc_base + L310_POWER_CTRL);
> > +
> > + /* Disable interrupts */
> > + writel_relaxed(0x00, at91_l2cc_base + L2X0_INTR_MASK);
> > + writel_relaxed(0x01ff, at91_l2cc_base + L2X0_INTR_CLEAR);
> > + l2x0_of_init(0, ~0UL);
> > +}
> > +#else
> > +static inline void at91_init_l2cache(void) {} #endif
> > +
> > static void __init sama5_dt_device_init(void) {
> > + at91_init_l2cache();
> > +
> > of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> > at91_sam9x5_pm_init();
> > }
> > --
> > 1.7.9.5
> >
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
Best Regards,
Wenyou Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
Dear Guenter, On Mon, 26 Jan 2015 20:08:04 -0800 Guenter Roeck wrote: > On 01/26/2015 07:49 PM, Jisheng Zhang wrote: > > Dear Doug, > > > > On Mon, 26 Jan 2015 15:27:15 -0800 > > Doug Anderson wrote: > > > >> On some dw_wdt implementations the "top" register may be initted to 0 > >> at bootup. In such a case, each "pat" of the watchdog will reset the > >> timer to 0x. That's pretty short. > >> > >> The input clock of the wdt can be any of a wide range of values. On > >> an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means > >> each tick is ~40ns and we'll count to 0x in ~2.6ms. > >> > >> Because of the above two facts, it's a really good idea to pat the > >> watchdog after initting the "top" register properly and before > >> enabling the watchdog. If you don't then there's no way we'll get the > >> next heartbeat in time. > >> > >> Jisheng Zhang fixed this problem on some dw_mmc versions by using the > > > > s/dw_mmc/dw_wdt > > > >> TOP_INIT feature. However, the dw_wdt on rk3288 doesn't have TOP_INIT > >> so it's a good idea to also pat the watchdog manually. > > > > Based on your register dumping, I see the following configurations on > > rk3288: > > > > WDT_DUAL_TOP is configured as false, so there's no TOP_INIT > > > > WDT_DFLT_TOP is configured as 0, so it will timeout soon. > > > > > > So an extra pat is a must on such platforms with similar configurations. > > And it doesn't hurt anything if we have an extra pat before enabling the > > WDT > > > > All in all, except the "dw_mmc" typo above, the patch looks good to me. > > > > Jisheng, > > it would be great if you can provide configuration information shown in > the (undocumented) registers. The wdt in rk3288 is a bit old, so I'm not sure whether the meaning is the same or not. The key related configuration here is the so called CP_WDT_DUAL_TOP, bit[2] of WDT_COMP_PARAMS_1 (0xf4), which indicates whether the TOP_INIT bits exist or fixed as zero. Thanks, Jisheng > > Doug, > > can you send another version with this information added as comment > to the code ? This will help others to understand what is going on > (and why) later on. > > Thanks, > Guenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the block tree with the vfs tree
On Mon, Jan 26, 2015 at 09:00:18PM -0700, Jens Axboe wrote:
> On 01/26/2015 08:57 PM, Stephen Rothwell wrote:
> >Hi Jens,
> >
> >Today's linux-next merge of the block tree got a conflict in
> >drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
> >vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
> >("block: loop: improve performance via blk-mq") and several others from
> >the block tree.
> >
> >I have no idea how fixed it up so I just used the version of the file
> >from the block tree (its been there a while). Please have a chat and
> >figure out how to combine these two large changes.
>
> Why isn't the loop patch in the block tree? That'd avoid such
> incidents. We could add a dependency for the required VFS patch.
I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
if you prefer to handle it that way - just tell. The first two patches
from that series would definitely go there; as for the rest... no preferences
here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] PXA1928 GPIO support
PXA1928 is an ARMv8 SOC in the PXA/MMP family. This series enables building on ARM64 and adds support for the PXA1928. The PXA1928 GPIO differs from previous generations by adding a 6th GPIO bank. Rob Rob Herring (3): gpio: pxa: remove mach IRQ includes dt/bindings: gpio: add compatible string for marvell,pxa1928-gpio gpio: pxa: add PXA1928 gpio type support .../devicetree/bindings/gpio/mrvl-gpio.txt | 4 +- drivers/gpio/gpio-pxa.c| 55 +- 2 files changed, 35 insertions(+), 24 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] dt/bindings: gpio: add compatible string for marvell,pxa1928-gpio
Add a new compatible string for PXA1928 GPIO controller. The IP block is same as prior chips with a 6th bank added. Signed-off-by: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/gpio/mrvl-gpio.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt index b2afdb2..67a2e4e 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt @@ -3,8 +3,8 @@ Required properties: - compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio", "intel,pxa27x-gpio", "intel,pxa3xx-gpio", - "marvell,pxa93x-gpio", "marvell,mmp-gpio" or - "marvell,mmp2-gpio". + "marvell,pxa93x-gpio", "marvell,mmp-gpio", + "marvell,mmp2-gpio" or marvell,pxa1928-gpio. - reg : Address and length of the register set for the device - interrupts : Should be the port interrupt shared by all gpio pins. There're three gpio interrupts in arch-pxa, and they're gpio0, -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16 v3] tracing: Add new file system tracefs
On Mon, Jan 26, 2015 at 09:34:19PM -0500, Steven Rostedt wrote: > On Mon, 26 Jan 2015 18:37:39 -0500 > Steven Rostedt wrote: > > > > > the first call of tracing_init_dentry(). Prior to that it's NULL. > > > BTW, may I politely inquire what the fuck are those contortions in > > > tracing_init_dentry_tr() about? Looks like a stunningly convoluted > > > way to trigger that automount point creation early in > > > tracer_init_tracefs(). Why not do that right there explicitly? > > > > Yeah, that could be cleaned up. Before the tracefs code, it made much > > more sense to keep that as a single function. Now that > > global_array.dir is treated differently as the subdirs, it does make > > sense to have global_arry.dir initialized in a separate function. > > > > I'll update my patch series to do this. > > Now I remember why I did this (as I changed the code and everything > blew up). The files in the tracing directory can be created by several > users (do a grep for fs_initcall() in kernel/trace/*.c). The first > caller to add a file initializes the tracing directory. > > I guess I can have all the other callers use fs_initcall_sync(). I'm > assuming those come after fs_initcall(). Ah... That explains some of the oddities of that kind (not all of them, though - your trace_options_init_dentry() is called by create_trace_option_dirs() and create_trace_option_core_file(), which is called only by create_trace_option_dirs(), and that - quite a few times, each time calling trace_options_init_dentry()). Strange style, IMO. Frankly, I'd rather have the ordering as explicit as it gets... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] gpio: pxa: remove mach IRQ includes
In preparation to enable ARCH_MMP on ARM64, the include of mach/irqs.h
must be eliminated. mach/irqs.h was being included for IRQ_GPIO{0,1},
but these IRQs are always passed in as resources now. We can use irq0
and irq1 and get rid of IRQ_GPIOx. Get rid of the ifdef in the process
as it is no longer needed.
Signed-off-by: Rob Herring
Cc: Linus Walleij
Cc: Alexandre Courbot
---
drivers/gpio/gpio-pxa.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index ad3feec..b4fb8de 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -27,8 +28,6 @@
#include
#include
-#include
-
/*
* We handle the GPIOs by banks, each bank covers up to 32 GPIOs with
* one set of registers. The register offsets are organized below:
@@ -629,19 +628,18 @@ static int pxa_gpio_probe(struct platform_device *pdev)
}
if (!use_of) {
-#ifdef CONFIG_ARCH_PXA
- irq = gpio_to_irq(0);
- irq_set_chip_and_handler(irq, _muxed_gpio_chip,
-handle_edge_irq);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
- irq_set_chained_handler(IRQ_GPIO0, pxa_gpio_demux_handler);
-
- irq = gpio_to_irq(1);
- irq_set_chip_and_handler(irq, _muxed_gpio_chip,
-handle_edge_irq);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
- irq_set_chained_handler(IRQ_GPIO1, pxa_gpio_demux_handler);
-#endif
+ if (irq0 > 0) {
+ irq = gpio_to_irq(0);
+ irq_set_chip_and_handler(irq, _muxed_gpio_chip,
+handle_edge_irq);
+ set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+ }
+ if (irq1 > 0) {
+ irq = gpio_to_irq(1);
+ irq_set_chip_and_handler(irq, _muxed_gpio_chip,
+handle_edge_irq);
+ set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+ }
for (irq = gpio_to_irq(gpio_offset);
irq <= gpio_to_irq(pxa_last_gpio); irq++) {
@@ -649,13 +647,13 @@ static int pxa_gpio_probe(struct platform_device *pdev)
handle_edge_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
}
- } else {
- if (irq0 > 0)
- irq_set_chained_handler(irq0, pxa_gpio_demux_handler);
- if (irq1 > 0)
- irq_set_chained_handler(irq1, pxa_gpio_demux_handler);
}
+ if (irq0 > 0)
+ irq_set_chained_handler(irq0, pxa_gpio_demux_handler);
+ if (irq1 > 0)
+ irq_set_chained_handler(irq1, pxa_gpio_demux_handler);
+
irq_set_chained_handler(irq_mux, pxa_gpio_demux_handler);
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] gpio: pxa: add PXA1928 gpio type support
Add support for PXA1928 GPIOs. The PXA1928 adds a 6th bank from previous
generations.
Signed-off-by: Jing Xiang
Signed-off-by: Xiangzhan Meng
[robh: ported to 3.19 from vendor kernel]
Signed-off-by: Rob Herring
Cc: Linus Walleij
Cc: Alexandre Courbot
---
drivers/gpio/gpio-pxa.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index b4fb8de..2fdb04b 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -41,9 +41,12 @@
* BANK 4 - 0x0104 0x0110 0x011C 0x0128 0x0134 0x0140 0x014C
* BANK 5 - 0x0108 0x0114 0x0120 0x012C 0x0138 0x0144 0x0150
*
+ * BANK 6 - 0x0200 0x020C 0x0218 0x0224 0x0230 0x023C 0x0248
+ *
* NOTE:
* BANK 3 is only available on PXA27x and later processors.
- * BANK 4 and 5 are only available on PXA935
+ * BANK 4 and 5 are only available on PXA935, PXA1928
+ * BANK 6 is only available on PXA1928
*/
#define GPLR_OFFSET0x00
@@ -56,7 +59,8 @@
#define GAFR_OFFSET0x54
#define ED_MASK_OFFSET 0x9C/* GPIO edge detection for AP side */
-#define BANK_OFF(n)(((n) < 3) ? (n) << 2 : 0x100 + (((n) - 3) << 2))
+#define BANK_OFF(n)(((n) < 3) ? (n) << 2 : ((n) > 5 ? 0x200 : 0x100)
\
+ + (((n) % 3) << 2))
int pxa_last_gpio;
static int irq_base;
@@ -92,6 +96,7 @@ enum pxa_gpio_type {
PXA93X_GPIO,
MMP_GPIO = 0x10,
MMP2_GPIO,
+ PXA1928_GPIO,
};
struct pxa_gpio_id {
@@ -139,6 +144,11 @@ static struct pxa_gpio_id mmp2_id = {
.gpio_nums = 192,
};
+static struct pxa_gpio_id pxa1928_id = {
+ .type = PXA1928_GPIO,
+ .gpio_nums = 224,
+};
+
#define for_each_gpio_chip(i, c) \
for (i = 0, c = _gpio_chips[0]; i <= pxa_last_gpio; i += 32, c++)
@@ -486,6 +496,7 @@ static int pxa_gpio_nums(struct platform_device *pdev)
case PXA93X_GPIO:
case MMP_GPIO:
case MMP2_GPIO:
+ case PXA1928_GPIO:
gpio_type = pxa_id->type;
count = pxa_id->gpio_nums - 1;
break;
@@ -505,6 +516,7 @@ static const struct of_device_id pxa_gpio_dt_ids[] = {
{ .compatible = "marvell,pxa93x-gpio", .data = _id, },
{ .compatible = "marvell,mmp-gpio", .data = _id, },
{ .compatible = "marvell,mmp2-gpio",.data = _id, },
+ { .compatible = "marvell,pxa1928-gpio", .data = _id, },
{}
};
@@ -666,6 +678,7 @@ static const struct platform_device_id gpio_id_table[] = {
{ "pxa93x-gpio",(unsigned long)_id },
{ "mmp-gpio", (unsigned long)_id },
{ "mmp2-gpio", (unsigned long)_id },
+ { "pxa1928-gpio", (unsigned long)_id },
{ },
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 07/12] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
Hi Sylvain,
> -Original Message-
> From: Sylvain Rochet [mailto:sylvain.roc...@finsecur.com]
> Sent: Monday, January 26, 2015 6:10 PM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; li...@arm.linux.org.uk;
> linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; alexandre.bell...@free-electrons.com;
> p...@axentia.se
> Subject: Re: [PATCH v2 07/12] pm: at91: the standby mode uses the same sram
> function as the suspend to memory mode
>
> Hello Wenyou,
>
>
> On Mon, Jan 26, 2015 at 05:42:11PM +0800, Wenyou Yang wrote:
> > +static int at91_pm_verify_clocks(suspend_state_t state)
> > {
> > unsigned long scsr;
> > int i;
> >
> > + /* For PM_SUSPEND_STANDBY, skip verifying the clock */
> > + if (state == PM_SUSPEND_STANDBY)
> > + return 1;
> > +
>
> In my opinion we should use the select() already in place in
> at91_pm_enter() to do that:
Accepted. Thanks
>
> > static int at91_pm_enter(suspend_state_t state) {
> > at91_pinctrl_gpio_suspend();
> >
> > switch (state) {
> (...)
> > + case PM_SUSPEND_MEM:
>
> /*
>* Ensure that clocks are in a valid state.
>*/
> if (!at91_pm_verify_clocks())
> goto error;
> /* FALLTHROUGH */
>
> > + case PM_SUSPEND_STANDBY:
> > /*
> > -* Suspend-to-RAM is like STANDBY plus slow clock mode, so
>
>
> Sylvain
Best Regards,
Wenyou Yang
RE: [PATCH 2/7] pm: at91: pm_suspend: add the WFI support for ARMv7
Hi Sergei, Thank you for your review. > -Original Message- > From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] > Sent: Monday, January 26, 2015 9:05 PM > To: Yang, Wenyou; Ferre, Nicolas; li...@arm.linux.org.uk > Cc: sylvain.roc...@finsecur.com; Vilchez, Patrice; > linux-kernel@vger.kernel.org; > alexandre.bell...@free-electrons.com; p...@axentia.se; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH 2/7] pm: at91: pm_suspend: add the WFI support for ARMv7 > > Hello. > > On 1/26/2015 1:06 PM, Wenyou Yang wrote: > > > Signed-off-by: Wenyou Yang > > --- > > arch/arm/mach-at91/pm_suspend.S | 54 > ++- > > 1 file changed, 53 insertions(+), 1 deletion(-) > > > diff --git a/arch/arm/mach-at91/pm_suspend.S > > b/arch/arm/mach-at91/pm_suspend.S index 122a3f1..e796722 100644 > > --- a/arch/arm/mach-at91/pm_suspend.S > > +++ b/arch/arm/mach-at91/pm_suspend.S > > @@ -53,6 +53,58 @@ mode .reqr6 > > beq 1b > > .endm > > > > +/* > > + * Put the processor to enter the WFI state */ > > + .macro _do_wfi > > + > > +#if defined(CONFIG_CPU_V7) > > + /* > > +* Execute an ISB instruction to flush the pipeline to ensure > > +* that all of operations have beem completed. > > Been. > > > +*/ > > + isb > > + > > + /* > > +* Execute an ISB instruction to ensure that all of the > > ISB again, while you're executing DSB/DMB? > Thank you for your pointing. > > +* CP15 register changes have been committed. > > +*/ > > + dsb > > + dmb > > + > > + /* Disable the processor's clock */ > > + mov tmp1, #AT91_PMC_PCK > > What's 'tmp1'? Is that a register name? Yes, a register name defined at the head of file. > > > + str tmp1, [pmc, #AT91_PMC_SCDR] > > + > > + /* Execute a WFI instruction */ > > Self-obvious comment, I'd say... > > > + wfi @ Wait For Interrupt > > + > > + /* > > +* CPU can specualatively prefetch the instructions > > Speculatively. Thanks. > > [...] > > WBR, Sergei Best Regards, Wenyou Yang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
On Mon, 26 Jan 2015 20:07:51 -0800 Guenter Roeck wrote: > On 01/26/2015 07:44 PM, Jisheng Zhang wrote: > > Dear Doug, > > > > On Mon, 26 Jan 2015 09:01:37 -0800 > > Doug Anderson wrote: > > > >> Jisheng, > >> > >> On Sun, Jan 25, 2015 at 10:22 PM, Jisheng Zhang > >> wrote: > Specifically I see the register WDT_TORR that has an offset of 0x4. > That's the RANGE_REG in your code. It shows bits 3:0 set the timeout > period (0 = 0x and 15 = 0x7fff). It shows bits 31:4 as > "reserved". > >>> > >>> Could you please dump registers' value at offset 0xf4 and 0xf8 if you > >>> don't mind? > >> > >> Those are not documented in the user manual that I have, but: > >> > > r(0xff8000f4) > >> 0x1a02 > > r(0xff8000f8) > >> 0x3130332a > > > Hi Jisheng, > > This translates to ascii "103*". How does it translate to "1.02a" ? aha, yes. wdt version is v1.03* ;) > > > Thanks. Now I got some information about your platform: > > > > wdt version: v1.02a > > > > WDT_DUAL_TOP is configured as false, so there's no TOP_INIT > > WDT_DFLT_TOP is configured as 0, so it will timeout soon. > > > Any chance you can provide the bit map for the register reporting > those flags ? will do in Doug's v2 patch thread Thanks, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16 v3] tracing: Add new file system tracefs
On Mon, Jan 26, 2015 at 08:03:50PM -0500, Steven Rostedt wrote: > On Mon, 26 Jan 2015 20:02:18 -0500 > Steven Rostedt wrote: > > > > Now you see why I found just dropping the parent mutex easier. > > And this is probably why kernfs does things the way it does. I can > imagine it having the same locking issues. The least said about kernfs locking, the better... As for the use of trace_types_lock to serialize rmdir vs. event addition/removal, I wonder what's wrong with actually using the ->i_mutex of /instances - you have a reference to its dentry, after all... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16 v3] tracing: Add new file system tracefs
On Mon, Jan 26, 2015 at 07:39:09PM -0500, Steven Rostedt wrote: > On Mon, 26 Jan 2015 18:49:16 -0500 > Steven Rostedt wrote: > > > On Mon, 26 Jan 2015 18:43:14 -0500 > > Steven Rostedt wrote: > > > > > That is, we can not hold i_mutex and take trace_types_lock. > > > > > > trace_types_lock needs to be held with the creation or destruction > > > of events, which is what mkdir an rmdir do. > > > > Although, I can not remember how this happened, but lockdep blew up on > > me with this. I'll look again. > > OK, found it. When events are created (module is loaded), the > trace_types_lock is taken, and the event directories are created (these > are in /sys/kernel/debug/tracing/events). We need to grab the i_mutex > in order to create these files. > > This means that we can not take the trace_types_lock within the mkdir > or rmdir calls. > > The directories are not static even outside the mkdir and rmdir calls. > As events can be created from several sources, which will create new > files and directories. Frankly, the first impression is that you have trace_types_lock way too high in the hierarchy - you are taking it well outside of the level where you start walking through ftrace_trace_arrays... What else is it used for? You seem to use it protect trace_array refcounts, but you use them in a very odd way... What happens if lookup for a file in that tree loses CPU just as it enters trace_array_get() (e.g. on the same trace_types_lock), at which point rm .../instances/ comes, sees that tr->ref is still zero, kicks the sucker out of the list and frees it, immediately followed by mkdir creating a new instace? If the allocation of the new trace_array happens to reuse the just-freed one, your trace_array_get() will actually succeed, won't it? It's not fatal (after all, everything will work as if you opened the similar file in new instance in the first place), but it looks rather bogus... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] at91: dt for 3.20 #2
On Mon, Jan 26, 2015 at 05:19:50PM +0100, Nicolas Ferre wrote: > Arnd, Olof, Kevin, > > Some more little modifications for the DT on several products. The > corresponding code in drivers is already queued in the relevant maintainers' > git trees and there are no dependencies. > > Thanks, best regards, > > The following changes since commit 4dd32e6d24932b0b0327d3a8ce526a56446e9b98: > > ARM: at91: dts: sama5d3: add ov2640 camera sensor support (2015-01-15 > 16:14:27 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git > tags/at91-dt2 > > for you to fetch changes up to c7f85be1fdd130490b8b525b8f3a821a59e75feb: > > ARM: at91/dt: sam9263: Add ac97 device node (2015-01-26 17:00:04 +0100) Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
On 01/26/2015 07:49 PM, Jisheng Zhang wrote: Dear Doug, On Mon, 26 Jan 2015 15:27:15 -0800 Doug Anderson wrote: On some dw_wdt implementations the "top" register may be initted to 0 at bootup. In such a case, each "pat" of the watchdog will reset the timer to 0x. That's pretty short. The input clock of the wdt can be any of a wide range of values. On an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means each tick is ~40ns and we'll count to 0x in ~2.6ms. Because of the above two facts, it's a really good idea to pat the watchdog after initting the "top" register properly and before enabling the watchdog. If you don't then there's no way we'll get the next heartbeat in time. Jisheng Zhang fixed this problem on some dw_mmc versions by using the s/dw_mmc/dw_wdt TOP_INIT feature. However, the dw_wdt on rk3288 doesn't have TOP_INIT so it's a good idea to also pat the watchdog manually. Based on your register dumping, I see the following configurations on rk3288: WDT_DUAL_TOP is configured as false, so there's no TOP_INIT WDT_DFLT_TOP is configured as 0, so it will timeout soon. So an extra pat is a must on such platforms with similar configurations. And it doesn't hurt anything if we have an extra pat before enabling the WDT All in all, except the "dw_mmc" typo above, the patch looks good to me. Jisheng, it would be great if you can provide configuration information shown in the (undocumented) registers. Doug, can you send another version with this information added as comment to the code ? This will help others to understand what is going on (and why) later on. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
On 01/26/2015 07:44 PM, Jisheng Zhang wrote: Dear Doug, On Mon, 26 Jan 2015 09:01:37 -0800 Doug Anderson wrote: Jisheng, On Sun, Jan 25, 2015 at 10:22 PM, Jisheng Zhang wrote: Specifically I see the register WDT_TORR that has an offset of 0x4. That's the RANGE_REG in your code. It shows bits 3:0 set the timeout period (0 = 0x and 15 = 0x7fff). It shows bits 31:4 as "reserved". Could you please dump registers' value at offset 0xf4 and 0xf8 if you don't mind? Those are not documented in the user manual that I have, but: r(0xff8000f4) 0x1a02 r(0xff8000f8) 0x3130332a Hi Jisheng, This translates to ascii "103*". How does it translate to "1.02a" ? Thanks. Now I got some information about your platform: wdt version: v1.02a WDT_DUAL_TOP is configured as false, so there's no TOP_INIT WDT_DFLT_TOP is configured as 0, so it will timeout soon. Any chance you can provide the bit map for the register reporting those flags ? Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 v2] UBI: Block: Add blk-mq support
On 01/26/2015 04:55 PM, Richard Weinberger wrote: Am 14.01.2015 um 09:39 schrieb Richard Weinberger: Am 14.01.2015 um 01:23 schrieb Jens Axboe: Which is as I suspected, you'll do each segment to the length specified, hence you don't need to track the returned count from blk_rq_map_sg(). Thanks a lot for the kind explanation, Jens! I'll add a comment the usage of blk_rq_map_sg() to avoid further confusion. Am I allowed to add your Reviewed-by too? Ping? I'd like to add a Reviewed-by to this patch. Yup sorry, looks OK to go in from my point of view. You can add my reviewed-by. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/ata/libata-core.c between commit 72dd299d5039 ("libata: allow
sata_sil24 to opt-out of tag ordered submission") from Linus' tree and
commit 98bd4be1ba95 ("libata: move sas ata tag allocation to
libata-scsi.c") from the block tree.
I fixed it up (I used the version from the block tree and then added
the following patch) and can carry the fix as necessary (no action is
required).
From: Stephen Rothwell
Date: Tue, 27 Jan 2015 14:59:51 +1100
Subject: [PATCH] libata: fix for move of sas tag allocation code
Signed-off-by: Stephen Rothwell
---
drivers/ata/libata-scsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index fd9be1756f0d..055e75d2176e 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -4240,7 +4240,10 @@ int ata_sas_allocate_tag(struct ata_port *ap)
unsigned int i, tag;
for (i = 0, tag = ap->sas_last_tag + 1; i < max_queue; i++, tag++) {
- tag = tag < max_queue ? tag : 0;
+ if (ap->flags & ATA_FLAG_LOWTAG)
+ tag = i;
+ else
+ tag = tag < max_queue ? tag : 0;
/* the last tag is reserved for internal command. */
if (tag == ATA_TAG_INTERNAL)
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpnOfJ45ZbBq.pgp
Description: OpenPGP digital signature
Re: cpuidle/powernv: Read target_residency value of idle states from DT if available
On 01/23/2015 10:29 AM, Michael Ellerman wrote:
> On Tue, 2015-20-01 at 11:26:49 UTC, Preeti U Murthy wrote:
>> @@ -177,34 +178,39 @@ static int powernv_add_idle_states(void)
>> return nr_idle_states;
>> }
>>
>> -idle_state_latency = of_get_property(power_mgt,
>> -"ibm,cpu-idle-state-latencies-ns", NULL);
>> -if (!idle_state_latency) {
>> +dt_idle_states = len_flags / sizeof(u32);
>> +
>> +latency_ns = kzalloc(sizeof(*latency_ns) * dt_idle_states, GFP_KERNEL);
>> +rc = of_property_read_u32(power_mgt,
>> +"ibm,cpu-idle-state-latencies-ns", latency_ns);
>
> That's only reading the first value.
>
> If you want to read the full property you need the _array version.
Right, thanks for pointing this out.
>
>> +if (rc) {
>> pr_warn("DT-PowerMgmt: missing
>> ibm,cpu-idle-state-latencies-ns\n");
>
> You missed my hint that "DT-PowerMgmt" is a weird and ugly prefix. Can you use
> "cpuidle-powernv:" instead?
Yes will change this.
>
>>
>> -dt_idle_states = len_flags / sizeof(u32);
>> +residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states,
>> GFP_KERNEL);
>> +rc = of_property_read_u32(power_mgt,
>> +"ibm,cpu-idle-state-residency-ns", residency_ns);
>> +if (rc) {
>> +pr_warn("DT-PowerMgmt: missing
>> ibm,cpu-idle-state-residency-ns\n");
>> +pr_warn("Falling back to default values\n");
>
> I don't think this is worth a warning seeing as we know there are firmwares
> out
> there which do not have the property.
>
>> for (i = 0; i < dt_idle_states; i++) {
>>
>> flags = be32_to_cpu(idle_state_flags[i]);
>> -
>> -/* Cpuidle accepts exit_latency in us and we estimate
>> - * target residency to be 10x exit_latency
>> +/*
>> + * Cpuidle accepts exit_latency and target_residency in us.
>> + * Use default target_residency values if f/w does not expose
>> it.
>> */
>> -latency_ns = be32_to_cpu(idle_state_latency[i]);
>> if (flags & OPAL_PM_NAP_ENABLED) {
>> /* Add NAP state */
>> strcpy(powernv_states[nr_idle_states].name, "Nap");
>> strcpy(powernv_states[nr_idle_states].desc, "Nap");
>> powernv_states[nr_idle_states].flags = 0;
>> -powernv_states[nr_idle_states].exit_latency =
>> -((unsigned int)latency_ns) / 1000;
>> -powernv_states[nr_idle_states].target_residency =
>> -((unsigned int)latency_ns / 100);
>> +powernv_states[nr_idle_states].target_residency = 100;
>> powernv_states[nr_idle_states].enter = _loop;
>> -nr_idle_states++;
>
> That looks wrong? Or do you mean to do that?
Are you pointing at removing the lines that populate the exit_latency ?
I read the latency value from the DT outside of these conditions because
it is guaranteed to be present at this point. We return back from this
function early on if we do not find it in the DT.
If you are pointing at the lines that remove increment of
nr_idle_states, it has to be done so towards the end of the iteration
because we are yet to populate the exit_latency and target_residency
outside of these conditions using this index.
Regards
Preeti U Murthy
>
> cheers
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] zram: free meta out of init_lock
Hello,
On (01/27/15 12:18), Minchan Kim wrote:
> Hello Sergey,
>
> On Tue, Jan 27, 2015 at 11:17:04AM +0900, Sergey Senozhatsky wrote:
> > On (01/27/15 01:00), Minchan Kim wrote:
> > > On Mon, Jan 26, 2015 at 11:17:09PM +0900, Sergey Senozhatsky wrote:
> > > > Hello,
> > > >
> > > > On (01/26/15 10:33), Minchan Kim wrote:
> > > > > Hello,
> > > > >
> > > > > On Sat, Jan 24, 2015 at 12:47:07AM +0900, Sergey Senozhatsky wrote:
> > > > > > On (01/23/15 15:48), Jerome Marchand wrote:
> > > > > > > On 01/23/2015 03:24 PM, Sergey Senozhatsky wrote:
> > > > > > > > On (01/23/15 14:58), Minchan Kim wrote:
> > > > > > > >> We don't need to call zram_meta_free, zcomp_destroy and zs_free
> > > > > > > >> under init_lock. What we need to prevent race with init_lock
> > > > > > > >> in reset is setting NULL into zram->meta (ie, init_done).
> > > > > > > >> This patch does it.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Minchan Kim
> > > > > > > >> ---
> > > > > > > >> drivers/block/zram/zram_drv.c | 28
> > > > > > > >>
> > > > > > > >> 1 file changed, 16 insertions(+), 12 deletions(-)
> > > > > > > >>
> > > > > > > >> diff --git a/drivers/block/zram/zram_drv.c
> > > > > > > >> b/drivers/block/zram/zram_drv.c
> > > > > > > >> index 9250b3f54a8f..0299d82275e7 100644
> > > > > > > >> --- a/drivers/block/zram/zram_drv.c
> > > > > > > >> +++ b/drivers/block/zram/zram_drv.c
> > > > > > > >> @@ -708,6 +708,7 @@ static void zram_reset_device(struct zram
> > > > > > > >> *zram, bool reset_capacity)
> > > > > > > >> {
> > > > > > > >>size_t index;
> > > > > > > >>struct zram_meta *meta;
> > > > > > > >> + struct zcomp *comp;
> > > > > > > >>
> > > > > > > >>down_write(>init_lock);
> > > > > > > >>
> > > > > > > >> @@ -719,20 +720,10 @@ static void zram_reset_device(struct
> > > > > > > >> zram *zram, bool reset_capacity)
> > > > > > > >>}
> > > > > > > >>
> > > > > > > >>meta = zram->meta;
> > > > > > > >> - /* Free all pages that are still in this zram device */
> > > > > > > >> - for (index = 0; index < zram->disksize >> PAGE_SHIFT;
> > > > > > > >> index++) {
> > > > > > > >> - unsigned long handle =
> > > > > > > >> meta->table[index].handle;
> > > > > > > >> - if (!handle)
> > > > > > > >> - continue;
> > > > > > > >> -
> > > > > > > >> - zs_free(meta->mem_pool, handle);
> > > > > > > >> - }
> > > > > > > >> -
> > > > > > > >> - zcomp_destroy(zram->comp);
> > > > > > > >
> > > > > > > > I'm not so sure about moving zcomp destruction. if we would
> > > > > > > > have detached it
> > > > > > > > from zram, then yes. otherwise, think of zram ->destoy vs
> > > > > > > > ->init race.
> > > > > > > >
> > > > > > > > suppose,
> > > > > > > > CPU1 waits for down_write() init lock in disksize_store() with
> > > > > > > > new comp already allocated;
> > > > > > > > CPU0 detaches ->meta and releases write init lock;
> > > > > > > > CPU1 grabs the lock and does zram->comp = comp;
> > > > > > > > CPU0 reaches the point of zcomp_destroy(zram->comp);
> > > > > > >
> > > > > > > I don't see your point: this patch does not call
> > > > > > > zcomp_destroy(zram->comp) anymore, but zram_destroy(comp), where
> > > > > > > comp is
> > > > > > > the old zram->comp.
> > > > > >
> > > > > >
> > > > > > oh... yes. sorry! my bad.
> > > > > >
> > > > > >
> > > > > >
> > > > > > anyway, on a second thought, do we even want to destoy meta out of
> > > > > > init_lock?
> > > > > >
> > > > > > I mean, it will let you init new device quicker. but... assume, you
> > > > > > have
> > > > > > 30G zram (or any other bad-enough number). on CPU0 you reset device
> > > > > > -- iterate
> > > > > > over 30G meta->table, etc. out of init_lock.
> > > > > > on CPU1 you concurrently re-init device and request again 30G.
> > > > > >
> > > > > > how bad that can be?
> > > > > >
> > > > > >
> > > > > >
> > > > > > diskstore called on already initialised device is also not so
> > > > > > perfect.
> > > > > > we first will try to allocate ->meta (vmalloc pages for another
> > > > > > 30G),
> > > > > > then allocate comp, then down_write() init lock to find out that
> > > > > > device
> > > > > > is initialised and we need to release allocated memory.
> > > > > >
> > > > > >
> > > > > >
> > > > > > may be we better keep ->meta destruction under init_lock and
> > > > > > additionally
> > > > > > move ->meta and ->comp allocation under init_lock in
> > > > > > disksize_store()?
> > > > > >
> > > > > > like the following one:
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > drivers/block/zram/zram_drv.c | 25 +
> > > > > > 1 file changed, 13 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/block/zram/zram_drv.c
> > > > > > b/drivers/block/zram/zram_drv.c
> > > > > > index 9250b3f..827ab21 100644
> > > > > > ---
Re: linux-next: manual merge of the block tree with the vfs tree
On 01/26/2015 08:57 PM, Stephen Rothwell wrote:
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
("block: loop: improve performance via blk-mq") and several others from
the block tree.
I have no idea how fixed it up so I just used the version of the file
from the block tree (its been there a while). Please have a chat and
figure out how to combine these two large changes.
Why isn't the loop patch in the block tree? That'd avoid such incidents.
We could add a dependency for the required VFS patch.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with the vfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/block/loop.c between commit c2ca80413553 ("loop: convert to
vfs_iter_read/write") from the vfs tree and commit b5dd2f6047ca
("block: loop: improve performance via blk-mq") and several others from
the block tree.
I have no idea how fixed it up so I just used the version of the file
from the block tree (its been there a while). Please have a chat and
figure out how to combine these two large changes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgptwWq_KjQ1f.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/5] mtd: nand: Add qcom nand controller driver
On 01/27/2015 02:35 AM, Kevin Cernekee wrote:
On Wed, Jan 21, 2015 at 10:36 PM, Archit Taneja wrote:
On 01/21/2015 06:24 AM, Daniel Ehrenberg wrote:
On Fri, Jan 16, 2015 at 6:48 AM, Archit Taneja
wrote:
+/*
+ * the bad block marker is readable only when we read the page with ECC
+ * disabled. all the read/write commands like NAND_CMD_READOOB,
NAND_CMD_READ0
+ * and NAND_CMD_PAGEPROG are executed in the driver with ECC enabled.
therefore,
+ * the default nand helper functions to detect a bad block or mark a bad
block
+ * can't be used.
+ */
+static int qcom_nandc_block_bad(struct mtd_info *mtd, loff_t ofs, int
getchip)
+{
+ int page, r, mark, bad = 0;
+ struct nand_chip *chip = mtd->priv;
+ struct nand_ecc_ctrl *ecc = >ecc;
+ int cwperpage = ecc->steps;
+ struct qcom_nandc_data *this = chip->priv;
+ u32 flash_status;
+
+ pre_command(this, NAND_CMD_NONE);
+
+ page = (int)(ofs >> chip->page_shift) & chip->pagemask;
+
+ /*
+* configure registers for a raw page read, the address is set to
the
+* beginning of the last codeword
+*/
+ this->use_ecc = false;
+ set_address(this, this->cw_size * (cwperpage - 1), page);
+
+ /* we just read one codeword that contains the bad block marker
*/
+ update_rw_regs(this, 1, true);
+
+ read_cw(this, this->cw_size, 0);
+
+ r = submit_descs(this);
+ if (r) {
+ dev_err(this->dev, "error submitting descs\n");
+ goto err;
+ }
+
+ flash_status = this->reg_read_buf[0];
+
+ /*
+* unable to read the marker successfully, is that sufficient to
report
+* the block as bad?
+*/
+ if (flash_status & (FS_OP_ERR | FS_MPU_ERR)) {
+ dev_warn(this->dev, "error while reading bad block
mark\n");
+ goto err;
+ }
+
+ mark = mtd->writesize - (this->cw_size * (cwperpage - 1));
+
+ if (chip->options & NAND_BUSWIDTH_16)
+ bad = this->data_buffer[mark] != 0xff ||
+ this->data_buffer[mark + 1] != 0xff;
+
+ bad = this->data_buffer[mark] != 0xff;
+err:
+ free_descs(this);
+
+ return bad;
+}
+
+static int qcom_nandc_block_markbad(struct mtd_info *mtd, loff_t ofs)
+{
+ int page, r;
+ struct nand_chip *chip = mtd->priv;
+ struct nand_ecc_ctrl *ecc = >ecc;
+ int cwperpage = ecc->steps;
+ struct qcom_nandc_data *this = chip->priv;
+ u32 flash_status;
+
+ pre_command(this, NAND_CMD_NONE);
+
+ /* fill our internal buffer's oob area with 0's */
+ memset(this->data_buffer, 0x00, mtd->writesize + mtd->oobsize);
+
+ page = (int)(ofs >> chip->page_shift) & chip->pagemask;
+
+ this->use_ecc = false;
+ set_address(this, this->cw_size * (cwperpage - 1), page);
+
+ /* we just write to one codeword that contains the bad block
marker*/
+ update_rw_regs(this, 1, false);
+
+ /*
+* overwrite the last codeword with 0s, this will result in
setting
+* the bad block marker to 0 too
+*/
+ write_cw(this, this->cw_size, 0);
+
+ r = submit_descs(this);
+ if (r) {
+ dev_err(this->dev, "error submitting descs\n");
+ r = -EIO;
+ goto err;
+ }
+
+ flash_status = this->reg_read_buf[0];
+
+ if (flash_status & (FS_OP_ERR | FS_MPU_ERR))
+ r = -EIO;
+
+err:
+ free_descs(this);
+
+ return r;
+}
Would it be possible to refactor this code so that it implements
generic read_oob_raw() and write_oob_raw() callbacks, which can
read/write arbitrary uncorrected OOB bytes instead of just the BBI?
Or is the controller limited in which OOB bytes can be directly
accessed?
When accessing the page with ECC disabled, there doesn't seem to be any
limitation.
We have 528/32 bytes per codeword, and we can access all of it in raw mode.
One advantage of implementing the generic raw read/write callbacks is
that the MTD subsystem already has logic to handle old NAND chips with
different BBI positions, bitflips in the BBI, and other corner cases.
Looks like this code marks block bad and reads bad block information
based on information in the OOB area. And in qcom_nandc_init,
NAND_SKIP_BBTSCAN is set, meaning that this is the code used in
practice on the chip in the mtd_block_isbad path. Can this driver be
used with an on-flash OOB table by editing the init function's chip
flags, or would it need more significant changes to allow that?
The code doesn't exactly read the OOB area. When the ECC HW block is
enabled, the bad block isn't in either oob or data area! We can access it
only when ECC is disabled. With ECC disabled, the bad block marker lies in
the last codeword somewhere in the middle of the user data. For the
mtd_read_oob()/write_oob() functions, we have the ECC always enabled, hence,
we never access the bad block marker through them
Re: [GIT PULL] PCI fixes for v3.19
On Mon, Jan 26, 2015 at 3:53 PM, Bjorn Helgaas wrote:
> On Mon, Jan 26, 2015 at 01:24:51PM -0800, Tony Luck wrote:
>> On Mon, Jan 26, 2015 at 1:02 PM, Bjorn Helgaas wrote:
>> > Sorry for the inconvenience. Can you collect a complete dmesg log and
>> > "lspci -vv" output, too (from the kernel with the reverted commit)?
>> > That will have more useful information than just /proc/iomem.
>>
>> Full dmesg, lspci -vv, and bonus .config (CONFIG_PCI_IOV is indeed
>> not set)
>
> The ROM part is something we should fix:
>
> pci :01:00.1: can't claim BAR 6 [mem 0xfffe-0x pref]: no
> compatible bridge window
>
> The ROM BAR is probably disabled, and we shouldn't complain about this if
> it's disabled. Yinghai?
original ia64 code, has extra checking to hide the warning
-static int is_valid_resource(struct pci_dev *dev, int idx)
{
- unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
- struct resource *devr = >resource[idx], *busr;
if (!dev->bus)
- return 0;
-
- pci_bus_for_each_resource(dev->bus, busr, i) {
- if (!busr || ((busr->flags ^ devr->flags) & type_mask))
- continue;
- if ((devr->start) && (devr->start >= busr->start) &&
- (devr->end <= busr->end))
- return 1;
- }
- return 0;
-}
also that is used to skip pci_claim_resource calling for invalid ...
so the root resource is totally wrong from ACPI.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
Dear Doug,
On Mon, 26 Jan 2015 15:27:15 -0800
Doug Anderson wrote:
> On some dw_wdt implementations the "top" register may be initted to 0
> at bootup. In such a case, each "pat" of the watchdog will reset the
> timer to 0x. That's pretty short.
>
> The input clock of the wdt can be any of a wide range of values. On
> an rk3288 system, I've seen the wdt clock be 24.75 MHz. That means
> each tick is ~40ns and we'll count to 0x in ~2.6ms.
>
> Because of the above two facts, it's a really good idea to pat the
> watchdog after initting the "top" register properly and before
> enabling the watchdog. If you don't then there's no way we'll get the
> next heartbeat in time.
>
> Jisheng Zhang fixed this problem on some dw_mmc versions by using the
s/dw_mmc/dw_wdt
> TOP_INIT feature. However, the dw_wdt on rk3288 doesn't have TOP_INIT
> so it's a good idea to also pat the watchdog manually.
Based on your register dumping, I see the following configurations on rk3288:
WDT_DUAL_TOP is configured as false, so there's no TOP_INIT
WDT_DFLT_TOP is configured as 0, so it will timeout soon.
So an extra pat is a must on such platforms with similar configurations. And it
doesn't hurt anything if we have an extra pat before enabling the WDT
All in all, except the "dw_mmc" typo above, the patch looks good to me.
Thanks,
Jisheng
>
> Signed-off-by: Doug Anderson
> ---
> Changes in v2:
> - Add comment about why TOP_INIT doesn't work on rk3288; move pat
> to right next to the attempt to use TOP_INIT.
>
> drivers/watchdog/dw_wdt.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
> index b34a2e4..2c24882 100644
> --- a/drivers/watchdog/dw_wdt.c
> +++ b/drivers/watchdog/dw_wdt.c
> @@ -96,6 +96,12 @@ static inline void dw_wdt_set_next_heartbeat(void)
> dw_wdt.next_heartbeat = jiffies + dw_wdt_get_top() * HZ;
> }
>
> +static void dw_wdt_keepalive(void)
> +{
> + writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
> +WDOG_COUNTER_RESTART_REG_OFFSET);
> +}
> +
> static int dw_wdt_set_top(unsigned top_s)
> {
> int i, top_val = DW_WDT_MAX_TOP;
> @@ -114,17 +120,18 @@ static int dw_wdt_set_top(unsigned top_s)
> writel(top_val | top_val << WDOG_TIMEOUT_RANGE_TOPINIT_SHIFT,
> dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
>
> + /*
> + * On some versions of dw_wdt writing to TOPINIT counts as a pat
> + * (kick) of the watchdog; for other version of dw_wdt bits 4-7
> + * are reserved and we need to pat the watchdog dog manually.
> + */
> + dw_wdt_keepalive();
> +
> dw_wdt_set_next_heartbeat();
>
> return dw_wdt_top_in_seconds(top_val);
> }
>
> -static void dw_wdt_keepalive(void)
> -{
> - writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
> -WDOG_COUNTER_RESTART_REG_OFFSET);
> -}
> -
> static int dw_wdt_restart_handle(struct notifier_block *this,
> unsigned long mode, void *cmd)
> {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: dw_wdt: pat the watchdog before enabling it
Dear Doug, On Mon, 26 Jan 2015 09:01:37 -0800 Doug Anderson wrote: > Jisheng, > > On Sun, Jan 25, 2015 at 10:22 PM, Jisheng Zhang wrote: > >> Specifically I see the register WDT_TORR that has an offset of 0x4. > >> That's the RANGE_REG in your code. It shows bits 3:0 set the timeout > >> period (0 = 0x and 15 = 0x7fff). It shows bits 31:4 as > >> "reserved". > > > > Could you please dump registers' value at offset 0xf4 and 0xf8 if you > > don't mind? > > Those are not documented in the user manual that I have, but: > > >>> r(0xff8000f4) > 0x1a02 > >>> r(0xff8000f8) > 0x3130332a Thanks. Now I got some information about your platform: wdt version: v1.02a WDT_DUAL_TOP is configured as false, so there's no TOP_INIT WDT_DFLT_TOP is configured as 0, so it will timeout soon. However, it doesn't hurt anything if we have an extra pat before enabling WDT Thanks, Jisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] PCI fixes for v3.19
On Mon, Jan 26, 2015 at 1:24 PM, Tony Luck wrote: > On Mon, Jan 26, 2015 at 1:02 PM, Bjorn Helgaas wrote: >> Sorry for the inconvenience. Can you collect a complete dmesg log and >> "lspci -vv" output, too (from the kernel with the reverted commit)? >> That will have more useful information than just /proc/iomem. > > Full dmesg, lspci -vv, and bonus .config (CONFIG_PCI_IOV is indeed > not set) Sorry for the problem. Can you please get boot bog with "debug ignore_logleve"? we should get print out from + dev_printk(KERN_DEBUG, >dev, "%pR clipped to %pR\n", +_res, res); Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] ASoC: codecs: wm8904: add dt ids table
From: Alexander Morozov
The WM8904 and WM8918 has the same data type, while the WM8912
has different data type. So, use the data in dt ids table to
distinguish them.
Signed-off-by: Alexander Morozov
[voice.s...@atmel.com: add code to distinguish device type]
Signed-off-by: Bo Shen
---
Changes in v3:
- Get the device type from match data in probe function.
Changes in v2:
- Add driver data for distinguish the device capability.
sound/soc/codecs/wm8904.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index 4d2d2b1..a80bc52 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -2098,6 +2098,24 @@ static const struct regmap_config wm8904_regmap = {
.num_reg_defaults = ARRAY_SIZE(wm8904_reg_defaults),
};
+#ifdef CONFIG_OF
+static enum wm8904_type wm8904_data = WM8904;
+static enum wm8904_type wm8912_data = WM8912;
+
+static const struct of_device_id wm8904_of_match[] = {
+ {
+ .compatible = "wlf,wm8904",
+ .data = _data,
+ }, {
+ .compatible = "wlf,wm8912",
+ .data = _data,
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, wm8904_of_match);
+#endif
+
static int wm8904_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -2125,7 +2143,17 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
return ret;
}
- wm8904->devtype = id->driver_data;
+ if (i2c->dev.of_node) {
+ const struct of_device_id *match;
+
+ match = of_match_node(wm8904_of_match, i2c->dev.of_node);
+ if (match == NULL)
+ return -EINVAL;
+ wm8904->devtype = *((enum wm8904_type *)match->data);
+ } else {
+ wm8904->devtype = id->driver_data;
+ }
+
i2c_set_clientdata(i2c, wm8904);
wm8904->pdata = i2c->dev.platform_data;
@@ -2259,6 +2287,7 @@ static struct i2c_driver wm8904_i2c_driver = {
.driver = {
.name = "wm8904",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(wm8904_of_match),
},
.probe =wm8904_i2c_probe,
.remove = wm8904_i2c_remove,
--
2.3.0.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] binding: wm8904: add new compatible string
The "wlf,wm8912" compatible string is used for wm8912, which share driver with wm8904, however, the data type is different. Signed-off-by: Bo Shen --- Changes in v3: None Changes in v2: None Documentation/devicetree/bindings/sound/wm8904.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt index e99f409..66bf261 100644 --- a/Documentation/devicetree/bindings/sound/wm8904.txt +++ b/Documentation/devicetree/bindings/sound/wm8904.txt @@ -3,7 +3,7 @@ WM8904 audio CODEC This device supports I2C only. Required properties: - - compatible: "wlf,wm8904" + - compatible: "wlf,wm8904" or "wlf,wm8912" - reg: the I2C address of the device. - clock-names: "mclk" - clocks: reference to -- 2.3.0.rc0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] tick/broadcast: Make movement of broadcast hrtimer robust against hotplug
On 01/22/2015 04:45 PM, Thomas Gleixner wrote: > On Thu, 22 Jan 2015, Preeti U Murthy wrote: >> On 01/21/2015 05:16 PM, Thomas Gleixner wrote: >> How about when the cpu that is going offline receives a timer interrupt >> just before setting its state to CPU_DEAD ? That is still possible right >> given that its clock devices may not have been shutdown and it is >> capable of receiving interrupts for a short duration. Even with the >> above patch, is the following scenario possible ? >> >> CPU0 CPU1 >> t0 Receives timer interrupt >> >> t1 Sees that there are hrtimers >>to be serviced (hrtimers are not yet migrated) >> >> t2 calls hrtimer_interrupt() >> >> t3 tick_program_event() CPU_DEAD notifiers >> CPU0's td->evtdev = NULL >> >> t4 clockevent_program_event() >>references NULL tick device pointer >> >> So my concern is that since the CLOCK_EVT_NOTIFY_CPU_DEAD callback >> handles shutting down of devices besides moving tick related duties. >> it's functions may race with the hotplug cpu still handling tick events. > > __cpu_disable() is supposed to block interrupts on the dying cpu. > > But I agree, we should make it more robust. So we want an explicit > call for disabling the cpu local stuff and an explicit takeover of the > broadcast duty. I'm anyway distangling the clockevents_notify() stuff, > so it should be simple to do so. I noticed that tick_handover_do_timer() function also suffers from the issue that the patch I posted for moving the broadcast duty had, in that it relies on all cpus participating in stop_machine(). In a design where all cpus do not participate in stop_machine(), if the freshly nominated do_timer cpu is idle, there is no update of jiffies till that cpu gets back to being busy. So we must do an explicit take over of *both* the broadcast and do_timer duty just before the CPU_DEAD phase. Regards Preeti U Murthy > Thanks, > > tglx > > > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: core: fix race condition in mmc_wait_data_done
Jialing Fu marvell.com> writes:
>
> The following panic is captured in ker3.14, but the issue still exists
> in latest kernel.
> -
> [ 20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer
dereference
> at virtual address 0578
> ..
> [ 20.738499] c0 3136 (Compiler) PC is at
_raw_spin_lock_irqsave+0x24/0x60
> [ 20.738527] c0 3136 (Compiler) LR is at
_raw_spin_lock_irqsave+0x20/0x60
> [ 20.740134] c0 3136 (Compiler) Call trace:
> [ 20.740165] c0 3136 (Compiler) []
_raw_spin_lock_irqsave+0x24/0x60
> [ 20.740200] c0 3136 (Compiler) [] __wake_up+0x1c/0x54
> [ 20.740230] c0 3136 (Compiler) []
mmc_wait_data_done+0x28/0x34
> [ 20.740262] c0 3136 (Compiler) []
mmc_request_done+0xa4/0x220
> [ 20.740314] c0 3136 (Compiler) []
sdhci_tasklet_finish+0xac/0x264
> [ 20.740352] c0 3136 (Compiler) []
tasklet_action+0xa0/0x158
> [ 20.740382] c0 3136 (Compiler) []
__do_softirq+0x10c/0x2e4
> [ 20.740411] c0 3136 (Compiler) [] irq_exit+0x8c/0xc0
> [ 20.740439] c0 3136 (Compiler) []
handle_IRQ+0x48/0xac
> [ 20.740469] c0 3136 (Compiler) []
gic_handle_irq+0x38/0x7c
> --
>
> Because in SMP, "mrq" has race condition between below two paths:
> path1: CPU0:
> static void mmc_wait_data_done(struct mmc_request *mrq)
> {
> mrq->host->context_info.is_done_rcv = true;
> //
> // If CPU0 has just finished "is_done_rcv = true" in path1, and at
> // this moment, IRQ or ICache line missing happens in CPU0.
> // What happens in CPU1 (path2)?
> //
> // If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
> // path2 would have chance to break from wait_event_interruptible
> // in mmc_wait_for_data_req_done and continue to run for next
> // mmc_request (mmc_blk_rw_rq_prep).
> //
> // Within mmc_blk_rq_prep, mrq is cleared to 0.
> // If below line still gets host from "mrq" as the result of
> // compiler, the panic happens as we traced.
> wake_up_interruptible(>host->context_info.wait);
> }
>
> path2: CPU1:
> static int mmc_wait_for_data_req_done(...
> {
> ...
> while (1) {
> wait_event_interruptible(context_info->wait,
> (context_info->is_done_rcv ||
>context_info->is_new_req));
>
> static void mmc_blk_rw_rq_prep(...
> {
> ...
> memset(brq, 0, sizeof(struct mmc_blk_request));
>
> This issue happens very coincidentally; however adding mdelay(1) in
> mmc_wait_data_done as below could duplicate it easily.
> static void mmc_wait_data_done(struct mmc_request *mrq)
> {
> mrq->host->context_info.is_done_rcv = true;
> mdelay(1);
> wake_up_interruptible(>host->context_info.wait);
> }
> At runtime, IRQ or ICache line missing may just happen at the same place
> of the mdelay(1).
>
> This patch gets the mmc_context_info at the beginning of function, it can
> avoid this race condition.
>
> Signed-off-by: Jialing Fu marvell.com>
> ---
> drivers/mmc/core/core.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 9584bff..f08c9a8 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> -326,8 +326,10 EXPORT_SYMBOL(mmc_start_bkops);
> */
> static void mmc_wait_data_done(struct mmc_request *mrq)
> {
> - mrq->host->context_info.is_done_rcv = true;
> - wake_up_interruptible(>host->context_info.wait);
> + struct mmc_context_info *context_info = >host->context_info;
> +
> + context_info->is_done_rcv = true;
> + wake_up_interruptible(_info->wait);
> }
>
> static void mmc_wait_done(struct mmc_request *mrq)
Hi Jialing,
I met the same issue at kernel v3.10, and after adding mdelay(1) to
mmc_wait_data_done() function, it could duplicate at every boot-up stage.
[ 15.157899] [] _raw_spin_lock_irqsave+0x2a/0x40
[ 15.157925] [] __wake_up+0x23/0x50
[ 15.157951] [] mmc_wait_data_done+0x3e/0x50
[ 15.157975] [] mmc_request_done+0xa6/0x250
[ 15.157999] [] ? _raw_spin_unlock_irqrestore+0x28/0x60
[ 15.158027] [] sdhci_tasklet_finish+0xeb/0x190
[ 15.158054] [] tasklet_action+0x6c/0xe0
[ 15.158077] [] __do_softirq+0x110/0x2d0
[ 15.158103] [] call_softirq+0x1c/0x30
[ 15.158127] [] do_softirq+0x6d/0xa0
[ 15.158150] [] irq_exit+0xb5/0xc0
[ 15.158172] [] do_IRQ+0x56/0xc0
[ 15.158195] [] common_interrupt+0x6f/0x6f
I have no idea whether this patch is work or not because of rarely hit ratio
even without your solution. However, I'll keep monitor this subject if it is
healthy to be merged.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 04/12] pm: at91: move the copying the sram function to the sram initializationi phase
Hi Sergei,
Thank you for your review.
> -Original Message-
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> Sent: Monday, January 26, 2015 8:57 PM
> To: Yang, Wenyou; Ferre, Nicolas; li...@arm.linux.org.uk
> Cc: sylvain.roc...@finsecur.com; linux-kernel@vger.kernel.org;
> alexandre.bell...@free-electrons.com; p...@axentia.se; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH v2 04/12] pm: at91: move the copying the sram function to
> the sram initializationi phase
>
> Hello.
>
> On 1/26/2015 12:40 PM, Wenyou Yang wrote:
>
> > To decrease the suspend time, move the copying the sram function to
> > the sram initialization phase, instead of every time go to suspend.
>
> > Signed-off-by: Wenyou Yang
> > Acked-by: Alexandre Belloni
> > ---
> > arch/arm/mach-at91/pm.c |7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
>
> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> > 5dd4e41..409185e 100644
> > --- a/arch/arm/mach-at91/pm.c
> > +++ b/arch/arm/mach-at91/pm.c
> > @@ -161,10 +161,6 @@ static int at91_pm_enter(suspend_state_t state)
> > * turning off the main oscillator; reverse on wakeup.
> > */
> > if (slow_clock) {
> > -#ifdef CONFIG_AT91_SLOW_CLOCK
> > - /* copy slow_clock handler to SRAM, and call it
> > */
> > - memcpy(slow_clock, at91_slow_clock,
> at91_slow_clock_sz);
> > -#endif
> > slow_clock(at91_pmc_base, at91_ramc_base[0],
> >at91_ramc_base[1],
> >at91_pm_data.memctrl);
> > @@ -272,6 +268,9 @@ static void __init at91_pm_sram_init(void)
> > sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
> > slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz,
> > false);
> >
> > + /* Copy slow_clock handler to SRAM, and call it */
>
> You're not calling it here.
>
> > + memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
> > +
> > put_node:
> > of_node_put(node);
> > }
>
> WBR, Sergei
Best Regards,
Wenyou Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 02/10] zsmalloc: decouple handle and object
Hello Ganesh,
On Mon, Jan 26, 2015 at 10:53:57AM +0800, Ganesh Mahendran wrote:
> Hello, Minchan
>
> 2015-01-21 14:14 GMT+08:00 Minchan Kim :
> > Currently, zram's handle encodes object's location directly so
> > it makes hard to support migration/compaction.
> >
> > This patch decouples handle and object via adding indirect layer.
> > For it, it allocates handle dynamically and returns it to user.
> > The handle is the address allocated by slab allocation so it's
> > unique and the memory allocated keeps object's position so that
> > we can get object's position from derefercing handle.
> >
> > Signed-off-by: Minchan Kim
> > ---
> > mm/zsmalloc.c | 90
> > ---
> > 1 file changed, 68 insertions(+), 22 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 0dec1fa..9436ee8 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -110,6 +110,8 @@
> > #define ZS_MAX_ZSPAGE_ORDER 2
> > #define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
> >
> > +#define ZS_HANDLE_SIZE (sizeof(unsigned long))
> > +
> > /*
> > * Object location (, ) is encoded as
> > * as single (unsigned long) handle value.
> > @@ -241,6 +243,7 @@ struct zs_pool {
> > char *name;
> >
> > struct size_class **size_class;
> > + struct kmem_cache *handle_cachep;
> >
> > gfp_t flags;/* allocation flags used when growing pool */
> > atomic_long_t pages_allocated;
> > @@ -269,6 +272,34 @@ struct mapping_area {
> > enum zs_mapmode vm_mm; /* mapping mode */
> > };
> >
> > +static int create_handle_cache(struct zs_pool *pool)
> > +{
> > + pool->handle_cachep = kmem_cache_create("zs_handle", ZS_HANDLE_SIZE,
> > + 0, 0, NULL);
> > + return pool->handle_cachep ? 0 : 1;
> > +}
> > +
> > +static void destroy_handle_cache(struct zs_pool *pool)
> > +{
> > + kmem_cache_destroy(pool->handle_cachep);
> > +}
> > +
> > +static unsigned long alloc_handle(struct zs_pool *pool)
> > +{
> > + return (unsigned long)kmem_cache_alloc(pool->handle_cachep,
> > + pool->flags & ~__GFP_HIGHMEM);
> > +}
> > +
> > +static void free_handle(struct zs_pool *pool, unsigned long handle)
> > +{
> > + kmem_cache_free(pool->handle_cachep, (void *)handle);
> > +}
> > +
> > +static void record_obj(unsigned long handle, unsigned long obj)
> > +{
> > + *(unsigned long *)handle = obj;
> > +}
> > +
> > /* zpool driver */
> >
> > #ifdef CONFIG_ZPOOL
> > @@ -595,13 +626,18 @@ static void *obj_location_to_handle(struct page
> > *page, unsigned long obj_idx)
> > * decoded obj_idx back to its original value since it was adjusted in
> > * obj_location_to_handle().
> > */
> > -static void obj_handle_to_location(unsigned long handle, struct page
> > **page,
> > +static void obj_to_location(unsigned long handle, struct page **page,
> > unsigned long *obj_idx)
> > {
> > *page = pfn_to_page(handle >> OBJ_INDEX_BITS);
> > *obj_idx = (handle & OBJ_INDEX_MASK) - 1;
> > }
> >
> > +static unsigned long handle_to_obj(unsigned long handle)
> > +{
> > + return *(unsigned long *)handle;
> > +}
> > +
> > static unsigned long obj_idx_to_offset(struct page *page,
> > unsigned long obj_idx, int class_size)
> > {
> > @@ -1153,7 +1189,7 @@ void *zs_map_object(struct zs_pool *pool, unsigned
> > long handle,
> > enum zs_mapmode mm)
> > {
> > struct page *page;
> > - unsigned long obj_idx, off;
> > + unsigned long obj, obj_idx, off;
> >
> > unsigned int class_idx;
> > enum fullness_group fg;
> > @@ -1170,7 +1206,8 @@ void *zs_map_object(struct zs_pool *pool, unsigned
> > long handle,
> > */
> > BUG_ON(in_interrupt());
> >
> > - obj_handle_to_location(handle, , _idx);
> > + obj = handle_to_obj(handle);
> > + obj_to_location(obj, , _idx);
> > get_zspage_mapping(get_first_page(page), _idx, );
> > class = pool->size_class[class_idx];
> > off = obj_idx_to_offset(page, obj_idx, class->size);
> > @@ -1195,7 +1232,7 @@ EXPORT_SYMBOL_GPL(zs_map_object);
> > void zs_unmap_object(struct zs_pool *pool, unsigned long handle)
> > {
> > struct page *page;
> > - unsigned long obj_idx, off;
> > + unsigned long obj, obj_idx, off;
> >
> > unsigned int class_idx;
> > enum fullness_group fg;
> > @@ -1204,7 +1241,8 @@ void zs_unmap_object(struct zs_pool *pool, unsigned
> > long handle)
> >
> > BUG_ON(!handle);
> >
> > - obj_handle_to_location(handle, , _idx);
> > + obj = handle_to_obj(handle);
> > + obj_to_location(obj, , _idx);
> > get_zspage_mapping(get_first_page(page), _idx, );
> > class = pool->size_class[class_idx];
> > off = obj_idx_to_offset(page, obj_idx, class->size);
> > @@ -1236,7
Re: patch-2.7.3 no longer applies relative symbolic link patches
Linus Torvalds writes: > Ugh. I don't see anything we can do about this on the git side, and I > do kind of understand why 'patch' would be worried about '..' files. > In a perfect world, patch would parse the filename and see that it > stays within the directory structure of the project, but that is a > rather harder thing to do than just say "no dot-dot files". It is unclear to me why "limit to the current directory and below" is such a big deal in the first place. If the user wants to apply a patch that touches ../etc/shadow, is the tool in the place to complain?" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] USB fixes for v3.19-rc
On Thu, Jan 22, 2015 at 01:36:33PM -0600, Felipe Balbi wrote: > Hi Greg, > > two more fixes needed from my side. Let me know if you prefer > to handle them differently. > > cheers > > The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc: > > Linux 3.19-rc5 (2015-01-18 18:02:20 +1200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/fixes-for-v3.19-rc6 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/zsmalloc: add log for module load/unload
Hello Ganesh, On Tue, Jan 27, 2015 at 10:07:53AM +0800, Ganesh Mahendran wrote: > Hello, Andrew > > 2015-01-27 7:19 GMT+08:00 Andrew Morton : > > On Sat, 24 Jan 2015 21:48:41 +0800 Ganesh Mahendran > > wrote: > > > >> Sometimes, we want to know whether a module is loaded or unloaded > >> from the log. > > > > Why? What's special about zsmalloc? > > > > Please provide much better justification than this. > > When I debug with the zsmalloc module built in kernel. > After system boots up, I did not see: > /sys/kernel/debug/zsmalloc dir. > > Although the reason for this is that I made a mistake. I > forgot to add debugfs entry in /etc/fstab. > But I think it is suitable to add information for a module load/unload. > Then we can get this by: > dmesg | grep zsmalloc. I understand your trouble but it's general problem, not zsmalloc specific. Then, if you really want to fix, you should approach more generic ways. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] zram: free meta out of init_lock
Hello Sergey,
On Tue, Jan 27, 2015 at 11:17:04AM +0900, Sergey Senozhatsky wrote:
> On (01/27/15 01:00), Minchan Kim wrote:
> > On Mon, Jan 26, 2015 at 11:17:09PM +0900, Sergey Senozhatsky wrote:
> > > Hello,
> > >
> > > On (01/26/15 10:33), Minchan Kim wrote:
> > > > Hello,
> > > >
> > > > On Sat, Jan 24, 2015 at 12:47:07AM +0900, Sergey Senozhatsky wrote:
> > > > > On (01/23/15 15:48), Jerome Marchand wrote:
> > > > > > On 01/23/2015 03:24 PM, Sergey Senozhatsky wrote:
> > > > > > > On (01/23/15 14:58), Minchan Kim wrote:
> > > > > > >> We don't need to call zram_meta_free, zcomp_destroy and zs_free
> > > > > > >> under init_lock. What we need to prevent race with init_lock
> > > > > > >> in reset is setting NULL into zram->meta (ie, init_done).
> > > > > > >> This patch does it.
> > > > > > >>
> > > > > > >> Signed-off-by: Minchan Kim
> > > > > > >> ---
> > > > > > >> drivers/block/zram/zram_drv.c | 28
> > > > > > >> 1 file changed, 16 insertions(+), 12 deletions(-)
> > > > > > >>
> > > > > > >> diff --git a/drivers/block/zram/zram_drv.c
> > > > > > >> b/drivers/block/zram/zram_drv.c
> > > > > > >> index 9250b3f54a8f..0299d82275e7 100644
> > > > > > >> --- a/drivers/block/zram/zram_drv.c
> > > > > > >> +++ b/drivers/block/zram/zram_drv.c
> > > > > > >> @@ -708,6 +708,7 @@ static void zram_reset_device(struct zram
> > > > > > >> *zram, bool reset_capacity)
> > > > > > >> {
> > > > > > >> size_t index;
> > > > > > >> struct zram_meta *meta;
> > > > > > >> +struct zcomp *comp;
> > > > > > >>
> > > > > > >> down_write(>init_lock);
> > > > > > >>
> > > > > > >> @@ -719,20 +720,10 @@ static void zram_reset_device(struct zram
> > > > > > >> *zram, bool reset_capacity)
> > > > > > >> }
> > > > > > >>
> > > > > > >> meta = zram->meta;
> > > > > > >> -/* Free all pages that are still in this zram device */
> > > > > > >> -for (index = 0; index < zram->disksize >> PAGE_SHIFT;
> > > > > > >> index++) {
> > > > > > >> -unsigned long handle =
> > > > > > >> meta->table[index].handle;
> > > > > > >> -if (!handle)
> > > > > > >> -continue;
> > > > > > >> -
> > > > > > >> -zs_free(meta->mem_pool, handle);
> > > > > > >> -}
> > > > > > >> -
> > > > > > >> -zcomp_destroy(zram->comp);
> > > > > > >
> > > > > > > I'm not so sure about moving zcomp destruction. if we would have
> > > > > > > detached it
> > > > > > > from zram, then yes. otherwise, think of zram ->destoy vs ->init
> > > > > > > race.
> > > > > > >
> > > > > > > suppose,
> > > > > > > CPU1 waits for down_write() init lock in disksize_store() with
> > > > > > > new comp already allocated;
> > > > > > > CPU0 detaches ->meta and releases write init lock;
> > > > > > > CPU1 grabs the lock and does zram->comp = comp;
> > > > > > > CPU0 reaches the point of zcomp_destroy(zram->comp);
> > > > > >
> > > > > > I don't see your point: this patch does not call
> > > > > > zcomp_destroy(zram->comp) anymore, but zram_destroy(comp), where
> > > > > > comp is
> > > > > > the old zram->comp.
> > > > >
> > > > >
> > > > > oh... yes. sorry! my bad.
> > > > >
> > > > >
> > > > >
> > > > > anyway, on a second thought, do we even want to destoy meta out of
> > > > > init_lock?
> > > > >
> > > > > I mean, it will let you init new device quicker. but... assume, you
> > > > > have
> > > > > 30G zram (or any other bad-enough number). on CPU0 you reset device
> > > > > -- iterate
> > > > > over 30G meta->table, etc. out of init_lock.
> > > > > on CPU1 you concurrently re-init device and request again 30G.
> > > > >
> > > > > how bad that can be?
> > > > >
> > > > >
> > > > >
> > > > > diskstore called on already initialised device is also not so perfect.
> > > > > we first will try to allocate ->meta (vmalloc pages for another 30G),
> > > > > then allocate comp, then down_write() init lock to find out that
> > > > > device
> > > > > is initialised and we need to release allocated memory.
> > > > >
> > > > >
> > > > >
> > > > > may be we better keep ->meta destruction under init_lock and
> > > > > additionally
> > > > > move ->meta and ->comp allocation under init_lock in disksize_store()?
> > > > >
> > > > > like the following one:
> > > > >
> > > > > ---
> > > > >
> > > > > drivers/block/zram/zram_drv.c | 25 +
> > > > > 1 file changed, 13 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/drivers/block/zram/zram_drv.c
> > > > > b/drivers/block/zram/zram_drv.c
> > > > > index 9250b3f..827ab21 100644
> > > > > --- a/drivers/block/zram/zram_drv.c
> > > > > +++ b/drivers/block/zram/zram_drv.c
> > > > > @@ -765,9 +765,18 @@ static ssize_t disksize_store(struct device *dev,
> > > > > return -EINVAL;
> > > > >
> > > > > disksize = PAGE_ALIGN(disksize);
> > > > > + down_write(>init_lock);
> > > >
