* [PATCH v3 0/3] introduce static_vm for ARM-specific static mapped area
From: Nicolas Pitre @ 2013-01-29 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129065656.GC5131@lge.com>
On Tue, 29 Jan 2013, Joonsoo Kim wrote:
> On Mon, Jan 28, 2013 at 01:04:24PM -0500, Nicolas Pitre wrote:
> > On Mon, 28 Jan 2013, Will Deacon wrote:
> >
> > > Hello,
> > >
> > > On Thu, Jan 24, 2013 at 01:28:51AM +0000, Joonsoo Kim wrote:
> > > > In current implementation, we used ARM-specific flag, that is,
> > > > VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
> > > > The purpose of static mapped area is to re-use static mapped area when
> > > > entire physical address range of the ioremap request can be covered
> > > > by this area.
> > > >
> > > > This implementation causes needless overhead for some cases.
> > > > For example, assume that there is only one static mapped area and
> > > > vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
> > > > deciding whether it is matched or not. Moreover, even if there is
> > > > no static mapped area and vmlist has 300 areas, every time we call
> > > > ioremap, we check 300 areas in now.
> > > >
> > > > If we construct a extra list for static mapped area, we can eliminate
> > > > above mentioned overhead.
> > > > With a extra list, if there is one static mapped area,
> > > > we just check only one area and proceed next operation quickly.
> > > >
> > > > In fact, it is not a critical problem, because ioremap is not frequently
> > > > used. But reducing overhead is better idea.
> > > >
> > > > Another reason for doing this work is for removing vm_struct list management,
> > > > entirely. For more information, look at the following link.
> > > > http://lkml.org/lkml/2012/12/6/184
> > >
> > > First patch looks good (removing the unused vmregion stuff) but I'm not so
> > > sure about the rest of it. If you really care about ioremap performance,
> > > perhaps it would be better to have a container struct around the vm_struct
> > > for static mappings and then stick them in an augmented rbtree so you can
> > > efficiently find the mapping encompassing a particular physical address?
> >
> > How can ioremap performance be a problem is the question I had since the
> > beginning.
> >
> > Firstly, ioremap is _not_ meant to be used in performance critical
> > paths.
> >
> > Secondly, there shouldn't be _that_ many entries on the vmlist such as
> > 300. That sounds a bit excessive.
> >
> > So please, can we discuss the reasons that motivated those patches in
> > the first place? Maybe that's where the actual problem is.
>
> Hello, Wiil and Nicolas.
> First of all, thanks for reviewing.
>
> There is another reason for doing this work.
> As mentioned above, I try to remove list management for vm_struct(vmlist),
> entirely. For that purpose, removing architecture dependency against vmlist
> is needed. Below link is for my RFC patch trying to remove list management
> for vm_struct.
>
> http://lkml.org/lkml/2012/12/6/184
OK, I get it now.
I do have comments on your patches. I'll provide them as a reply to
them.
Nicolas
^ permalink raw reply
* [PATCH v3 1/3] ARM: vmregion: remove vmregion code entirely
From: Nicolas Pitre @ 2013-01-29 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358990934-4893-2-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, 24 Jan 2013, Joonsoo Kim wrote:
> From: Joonsoo Kim <js1304@gmail.com>
>
> Now, there is no user for vmregion.
> So remove it.
>
> Signed-off-by: Joonsoo Kim <js1304@gmail.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
> index 8a9c4cb..4e333fa 100644
> --- a/arch/arm/mm/Makefile
> +++ b/arch/arm/mm/Makefile
> @@ -6,7 +6,7 @@ obj-y := dma-mapping.o extable.o fault.o init.o \
> iomap.o
>
> obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
> - mmap.o pgd.o mmu.o vmregion.o
> + mmap.o pgd.o mmu.o
>
> ifneq ($(CONFIG_MMU),y)
> obj-y += nommu.o
> diff --git a/arch/arm/mm/vmregion.c b/arch/arm/mm/vmregion.c
> deleted file mode 100644
> index a631016..0000000
> --- a/arch/arm/mm/vmregion.c
> +++ /dev/null
> @@ -1,205 +0,0 @@
> -#include <linux/fs.h>
> -#include <linux/spinlock.h>
> -#include <linux/list.h>
> -#include <linux/proc_fs.h>
> -#include <linux/seq_file.h>
> -#include <linux/slab.h>
> -
> -#include "vmregion.h"
> -
> -/*
> - * VM region handling support.
> - *
> - * This should become something generic, handling VM region allocations for
> - * vmalloc and similar (ioremap, module space, etc).
> - *
> - * I envisage vmalloc()'s supporting vm_struct becoming:
> - *
> - * struct vm_struct {
> - * struct vmregion region;
> - * unsigned long flags;
> - * struct page **pages;
> - * unsigned int nr_pages;
> - * unsigned long phys_addr;
> - * };
> - *
> - * get_vm_area() would then call vmregion_alloc with an appropriate
> - * struct vmregion head (eg):
> - *
> - * struct vmregion vmalloc_head = {
> - * .vm_list = LIST_HEAD_INIT(vmalloc_head.vm_list),
> - * .vm_start = VMALLOC_START,
> - * .vm_end = VMALLOC_END,
> - * };
> - *
> - * However, vmalloc_head.vm_start is variable (typically, it is dependent on
> - * the amount of RAM found at boot time.) I would imagine that get_vm_area()
> - * would have to initialise this each time prior to calling vmregion_alloc().
> - */
> -
> -struct arm_vmregion *
> -arm_vmregion_alloc(struct arm_vmregion_head *head, size_t align,
> - size_t size, gfp_t gfp, const void *caller)
> -{
> - unsigned long start = head->vm_start, addr = head->vm_end;
> - unsigned long flags;
> - struct arm_vmregion *c, *new;
> -
> - if (head->vm_end - head->vm_start < size) {
> - printk(KERN_WARNING "%s: allocation too big (requested %#x)\n",
> - __func__, size);
> - goto out;
> - }
> -
> - new = kmalloc(sizeof(struct arm_vmregion), gfp);
> - if (!new)
> - goto out;
> -
> - new->caller = caller;
> -
> - spin_lock_irqsave(&head->vm_lock, flags);
> -
> - addr = rounddown(addr - size, align);
> - list_for_each_entry_reverse(c, &head->vm_list, vm_list) {
> - if (addr >= c->vm_end)
> - goto found;
> - addr = rounddown(c->vm_start - size, align);
> - if (addr < start)
> - goto nospc;
> - }
> -
> - found:
> - /*
> - * Insert this entry after the one we found.
> - */
> - list_add(&new->vm_list, &c->vm_list);
> - new->vm_start = addr;
> - new->vm_end = addr + size;
> - new->vm_active = 1;
> -
> - spin_unlock_irqrestore(&head->vm_lock, flags);
> - return new;
> -
> - nospc:
> - spin_unlock_irqrestore(&head->vm_lock, flags);
> - kfree(new);
> - out:
> - return NULL;
> -}
> -
> -static struct arm_vmregion *__arm_vmregion_find(struct arm_vmregion_head *head, unsigned long addr)
> -{
> - struct arm_vmregion *c;
> -
> - list_for_each_entry(c, &head->vm_list, vm_list) {
> - if (c->vm_active && c->vm_start == addr)
> - goto out;
> - }
> - c = NULL;
> - out:
> - return c;
> -}
> -
> -struct arm_vmregion *arm_vmregion_find(struct arm_vmregion_head *head, unsigned long addr)
> -{
> - struct arm_vmregion *c;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&head->vm_lock, flags);
> - c = __arm_vmregion_find(head, addr);
> - spin_unlock_irqrestore(&head->vm_lock, flags);
> - return c;
> -}
> -
> -struct arm_vmregion *arm_vmregion_find_remove(struct arm_vmregion_head *head, unsigned long addr)
> -{
> - struct arm_vmregion *c;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&head->vm_lock, flags);
> - c = __arm_vmregion_find(head, addr);
> - if (c)
> - c->vm_active = 0;
> - spin_unlock_irqrestore(&head->vm_lock, flags);
> - return c;
> -}
> -
> -void arm_vmregion_free(struct arm_vmregion_head *head, struct arm_vmregion *c)
> -{
> - unsigned long flags;
> -
> - spin_lock_irqsave(&head->vm_lock, flags);
> - list_del(&c->vm_list);
> - spin_unlock_irqrestore(&head->vm_lock, flags);
> -
> - kfree(c);
> -}
> -
> -#ifdef CONFIG_PROC_FS
> -static int arm_vmregion_show(struct seq_file *m, void *p)
> -{
> - struct arm_vmregion *c = list_entry(p, struct arm_vmregion, vm_list);
> -
> - seq_printf(m, "0x%08lx-0x%08lx %7lu", c->vm_start, c->vm_end,
> - c->vm_end - c->vm_start);
> - if (c->caller)
> - seq_printf(m, " %pS", (void *)c->caller);
> - seq_putc(m, '\n');
> - return 0;
> -}
> -
> -static void *arm_vmregion_start(struct seq_file *m, loff_t *pos)
> -{
> - struct arm_vmregion_head *h = m->private;
> - spin_lock_irq(&h->vm_lock);
> - return seq_list_start(&h->vm_list, *pos);
> -}
> -
> -static void *arm_vmregion_next(struct seq_file *m, void *p, loff_t *pos)
> -{
> - struct arm_vmregion_head *h = m->private;
> - return seq_list_next(p, &h->vm_list, pos);
> -}
> -
> -static void arm_vmregion_stop(struct seq_file *m, void *p)
> -{
> - struct arm_vmregion_head *h = m->private;
> - spin_unlock_irq(&h->vm_lock);
> -}
> -
> -static const struct seq_operations arm_vmregion_ops = {
> - .start = arm_vmregion_start,
> - .stop = arm_vmregion_stop,
> - .next = arm_vmregion_next,
> - .show = arm_vmregion_show,
> -};
> -
> -static int arm_vmregion_open(struct inode *inode, struct file *file)
> -{
> - struct arm_vmregion_head *h = PDE(inode)->data;
> - int ret = seq_open(file, &arm_vmregion_ops);
> - if (!ret) {
> - struct seq_file *m = file->private_data;
> - m->private = h;
> - }
> - return ret;
> -}
> -
> -static const struct file_operations arm_vmregion_fops = {
> - .open = arm_vmregion_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = seq_release,
> -};
> -
> -int arm_vmregion_create_proc(const char *path, struct arm_vmregion_head *h)
> -{
> - proc_create_data(path, S_IRUSR, NULL, &arm_vmregion_fops, h);
> - return 0;
> -}
> -#else
> -int arm_vmregion_create_proc(const char *path, struct arm_vmregion_head *h)
> -{
> - return 0;
> -}
> -#endif
> diff --git a/arch/arm/mm/vmregion.h b/arch/arm/mm/vmregion.h
> deleted file mode 100644
> index 0f5a5f2..0000000
> --- a/arch/arm/mm/vmregion.h
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -#ifndef VMREGION_H
> -#define VMREGION_H
> -
> -#include <linux/spinlock.h>
> -#include <linux/list.h>
> -
> -struct page;
> -
> -struct arm_vmregion_head {
> - spinlock_t vm_lock;
> - struct list_head vm_list;
> - unsigned long vm_start;
> - unsigned long vm_end;
> -};
> -
> -struct arm_vmregion {
> - struct list_head vm_list;
> - unsigned long vm_start;
> - unsigned long vm_end;
> - int vm_active;
> - const void *caller;
> -};
> -
> -struct arm_vmregion *arm_vmregion_alloc(struct arm_vmregion_head *, size_t, size_t, gfp_t, const void *);
> -struct arm_vmregion *arm_vmregion_find(struct arm_vmregion_head *, unsigned long);
> -struct arm_vmregion *arm_vmregion_find_remove(struct arm_vmregion_head *, unsigned long);
> -void arm_vmregion_free(struct arm_vmregion_head *, struct arm_vmregion *);
> -
> -int arm_vmregion_create_proc(const char *, struct arm_vmregion_head *);
> -
> -#endif
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
From: Cyril Chemparathy @ 2013-01-29 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359403945-28585-2-git-send-email-mugunthanvnm@ti.com>
On 01/28/2013 03:12 PM, Mugunthan V N wrote:
> Add helper functions for VLAN ALE implementations for Add, Delete
> Dump VLAN related ALE entries
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> drivers/net/ethernet/ti/cpsw_ale.c | 172 ++++++++++++++++++++++++++++++++++--
> drivers/net/ethernet/ti/cpsw_ale.h | 11 +++
> 2 files changed, 178 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
> index 0e9ccc2..0d7a60a 100644
> --- a/drivers/net/ethernet/ti/cpsw_ale.c
> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
[...]
> +int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
> + int reg_mcast, int unreg_mcast)
[...]
> +int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port)
[...]
> +int cpsw_ale_vlan_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
> + int flags, u16 vid)
[...]
> +int cpsw_ale_vlan_del_ucast(struct cpsw_ale *ale, u8 *addr, int port, u16 vid)
[...]
> +int cpsw_ale_vlan_add_mcast(struct cpsw_ale *ale, u8 *addr,
> + int port_mask, u16 vid, int super, int mcast_state)
[...]
> +int cpsw_ale_vlan_del_mcast(struct cpsw_ale *ale, u8 *addr,
> + int port_mask, u16 vid)
Are the VLAN and non-VLAN variants different enough to justify separate
implementations for all these functions? Could we collapse these by
generalizing the original to take an optional vlan argument instead?
Thanks
-- Cyril.
^ permalink raw reply
* [GIT PULL] vexpress: drivers for v3.9
From: Olof Johansson @ 2013-01-29 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359484450.8090.27.camel@hornet>
Hi,
On Tue, Jan 29, 2013 at 10:34 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> Hi Arnd, Olof,
>
> The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
>
> Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/pawelmoll/linux.git tags/vexpress/drivers-for-3.9
>
> for you to fetch changes up to d299d4b5c95d37df0a8964930a3586f8d3cdb4ef:
>
> arm: Move sp810.h to include/linux/amba/ (2013-01-29 18:13:24 +0000)
>
> ----------------------------------------------------------------
> Versatile Express related driver updates for 3.9:
> * Move sp810 header to a more generic location,
> mainly to share it with arm64
> * Add pseudo-GPIO lines (and equivalent gpio LED definitions)
> to control LEDs on vexpress motherboard.
>
> ----------------------------------------------------------------
> Catalin Marinas (1):
> arm: Move sp810.h to include/linux/amba/
>
> Pawel Moll (1):
> mfd: vexpress: Add pseudo-GPIO based LEDs
I can't find record of this patch ever having been posted (under that
subject at least) on any list I am on, including linux-arm-kernel and
linux-kernel.
You should at least post it to those lists, and cc the MFD maintainer.
And you should get his ack if you are going to merge this patch
through arm-soc instead of through his tree.
-Olof
^ permalink raw reply
* [RFC PATCH 0/2] ARM: update cpuinfo to print CPU model name
From: Nishanth Menon @ 2013-01-29 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB=otbSV6CH4WOrr577bHXFcjEVRGjZxatgy4CJ3cr0M0h4vfw@mail.gmail.com>
On 01:08-20130130, Ruslan Bilovol wrote:
> Hi,
>
> On Tue, Jan 29, 2013 at 6:02 PM, Nishanth Menon <nm@ti.com> wrote:
> >
> > On 17:54-20130129, Ruslan Bilovol wrote:
> > > Hi,
> > >
> > > The following patches update cpuinfo to print CPU
> > > model name for ARM. First patch exactly makes needed
> > > changes for ARM architecture.
> > > Second patch adds this ability to OMAP4 SoCs.
> > >
> > > This adds a common approach to show SoC name.
> > >
> > > Looks like there were few attempts to do similar
> > > changes to cpuinfo without any luck.
> > >
> > > So - comments are welcome
> > >
> > > Ruslan Bilovol (2):
> > > ARM: kernel: update cpuinfo to print CPU model name
> > > ARM: OMAP4: setup CPU model name during ID initialisation
> >
> > We had an discussion on similar lines but a generic suggestion:
> > https://patchwork.kernel.org/patch/98720/
> > SoCinfo framework which was supposed to introduce this
> >
> > Would'nt that be a better approach to take than an OMAP only solution?
>
> My goal is only to say what is the SoC model name in the /proc/cpuinfo
> (And it is not an OMAP-only solution - it is common. Support for OMAP
> is added in second patch)
> This is the only type of information that we can apply for any SoC.
> My point is - any SoC-specific information should go through some other
> way - like SoCinfo framework mentioned by you.
> And additional point - in cpuinfo we already have CPU name and Machine name.
> The SoC name (that is something between these two things) looks also relevant
Looking at the sample output in patch #1/2
OMAP4470 ES1.0 HS
OMAP4470 is SoC name
ES1.0 is SoC revision
HS is SoC type
We even have SoC features (e.g. at boot NEON etc..)
Is the intent to put all this inside /proc/cpuinfo?? I bet every SoC has
it's own interesting data it'd like to have (like some of the info
populated by DT even). I am hardpressed to think this fits inside
/proc/cpuinfo. I might even suspect that the list of interesting
information might even vary per SoC.
having machine name is something ARM specific? dumping it on my linux
machines (x86[1] and sparc[2]) dont seem to show that.
but in the interest of not breaking existing interfaces, new interfaces
should potentially belong elsewhere.. my 2 cents.
[1] http://pastebin.com/CF8HPDAC (Xubuntu 12.04 3.2.0-36)
[2] http://pastebin.com/qNwWHwiu (Debian 3.2.35-2)
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v4 0/9] ARM: S3C24XX: rework irq handling for a later dt usage
From: Kukjin Kim @ 2013-01-29 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301272124.18530.heiko@sntech.de>
Heiko St?bner wrote:
>
> This v4 does not change any code part. The patches are merely rebased
> to apply to the next/cleanup-s3c24xx branch as requested.
>
> Heiko Stuebner (9):
> ARM: S3C24XX: transform irq handling into a declarative form
> ARM: S3C24XX: Move irq syscore-ops to irq-pm
> ARM: S3C24XX: Modify s3c_irq_wake to use the hwirq property
> ARM: S3C24XX: move s3c2416 irq init to common irq code
> ARM: S3C24XX: modify s3c2416 irq init to initialize all irqs
> ARM: S3C24XX: transform s3c2416 irqs into new structure
> ARM: S3C24XX: move s3c2443 irq code to irq.c
> ARM: S3C24XX: modify s3c2443 irq init to initialize all irqs
> ARM: S3C24XX: transform s3c2443 subirqs into new structure
>
> arch/arm/mach-s3c24xx/Makefile | 4 +-
> arch/arm/mach-s3c24xx/common.h | 2 +
> arch/arm/mach-s3c24xx/irq-pm.c | 41 +-
> arch/arm/mach-s3c24xx/irq-s3c2416.c | 348 --------
> arch/arm/mach-s3c24xx/irq-s3c2443.c | 281 -------
> arch/arm/mach-s3c24xx/mach-smdk2416.c | 2 +-
> arch/arm/mach-s3c24xx/mach-smdk2443.c | 2 +-
> arch/arm/mach-s3c24xx/s3c2410.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2412.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2416.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2440.c | 4 +-
> arch/arm/mach-s3c24xx/s3c2442.c | 4 +-
> arch/arm/plat-s3c24xx/Kconfig | 1 +
> arch/arm/plat-s3c24xx/irq.c | 1110
+++++++++++++++-----------
> arch/arm/plat-samsung/include/plat/pm.h | 6 -
> arch/arm/plat-samsung/include/plat/s3c2416.h | 1 +
> arch/arm/plat-samsung/include/plat/s3c2443.h | 2 +
> 17 files changed, 688 insertions(+), 1132 deletions(-)
> delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2416.c
> delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2443.c
>
> --
> 1.7.10.4
Looks good to me, applied.
Thanks.
- Kukjin
^ permalink raw reply
* s3c2410 (Linux 2.6.36) Incorrect DRAM size
From: Woody Wu @ 2013-01-29 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVe3=cCLuELB7tuHp2Qis6_2EL_Q_XgC+aUk4398HysPSQ@mail.gmail.com>
? 2012-11-17 AM1:29?"Vasily Khoruzhick" <anarsoul@gmail.com>???
>
> On Fri, Nov 16, 2012 at 8:19 PM, Woody Wu <narkewoody@gmail.com> wrote:
> > Hi,
> >
> > I just buit a 2.6.36 and boot it from a s3c2410 board. At the very
> > beginning of consol log, the kernel reports the DRAM size if 16M.
> > (Memory: 16M = 16M total). But the board actually has 64M ram in two
> > bands (each is 32M).
> >
> > Did someone know the cause and have a hint or solution? And, does anyone
> > knows that the DRAM size is auto-detected by kernel or hard configured
> > in some .h?
>
> Bootloader passes ATAGs with memory location and size, so something's
> wrong with your bootloader.
Sorry only see ur reply after such long time. The problem solved. The
bootloader did not have a problem, but it was not passing ATAGs, so I have
to config the kernel to parse old parameter format.
Thanks anyway.
>
> Regards
> Vasily
>
> > Thanks in advance
> >
> > --
> > -woody
> > I can't go back to yesterday - because I was a different person then.
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130130/51e68791/attachment-0001.html>
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51082C4E.5050903@gmail.com>
On Tue, Jan 29, 2013 at 09:08:46PM +0100, Sebastian Hesselbarth wrote:
> On 01/29/2013 08:42 PM, Simon Baatz wrote:
> >On Mon, Jan 28, 2013 at 07:48:24PM -0500, Jason Cooper wrote:
> >>On Mon, Jan 28, 2013 at 11:31:48PM +0100, Simon Baatz wrote:
> >>>Nothing special here. My config originally based on a Debian config
> >>>for a Kirkwood kernel. Thus, amongst other drivers, mv643xx_eth is
> >>>build as a module and is loaded from an initrd.
> >>>Because all relevant drivers are loaded as modules, I need my
> >>>runit patch to boot at all.
> >>
> >>Let's back up. If you config early printk and COMMON_CLK_DEBUG and a
> >>vanilla v3.8-rc5 with your current config, what happens?
> >
> >I thought it's clear what happens. "runit" is requested in the dts by
> >serial, spi, watchdog, nand, i2c. Each of these are either not built
> >or built as a module in my config, except serial.
>
> Simon,
>
> it is clear what happens but just to blindly disable clock gating will
> not help here. What you are suffering are several issues not only one.
Sure it is more than one issue. That's why I ran different scenarios.
>
> >of_serial.c does the following in of_platform_serial_setup():
> >
> > if (of_property_read_u32(np, "clock-frequency",&clk)) {
> >
> > /* Get clk rate through clk driver if present */
> > info->clk = clk_get(&ofdev->dev, NULL);
> > if (IS_ERR(info->clk)) {
> > dev_warn(&ofdev->dev,
> > "clk or clock-frequency not defined\n");
> > return PTR_ERR(info->clk);
> > }
> >
> > clk_prepare_enable(info->clk);
> > clk = clk_get_rate(info->clk);
> > }
> >
> >and since "clock-frequency" is still given in the standard DTS for
> >the IB-NAS 6210, it does not enable the clock.
> >Thus, no driver uses the clock, it gets disabled and the system locks
> >up.
> >The system boots when removing "clock-frequency" from the DTS.
> >
> >Which lead to two questions:
> >- Is it safe to remove "clock-frequency" now that we have the clocks
> > in place?
>
> Safe, as long as you replace it with the corresponding clocks=<&..> property.
>
> >- The behavior of of_serial.c looks strange to me, is this really the
> >desired behavior?
>
> I guess it is, rely on clock-frequency because a lot of boards still use it.
> There was no clocks property in of_serial when we started with kirkwood and
> dove. I think we can switch now to clocks property which will also remove
> all hard coded occurrences of tclk frequency.
>
> >For the "runit" clock, this means that any time you hit a
> >configuration that does not keep the clock enabled, the system will
> >lockup. (We have gone through this more than once now. Especially,
> >this hits you hard when you try to support a new board and disable as
> >much as possible in the config/dts for a start...).
>
> Well, if there is no device/driver using runit it should be safe to disable
> it. If there is a driver using it, we need a clocks property for it. And
> as you already stated, serial is using it. And you want serial in every
> minimal kernel, don't you?
>From f479db4:
Marvell engineers tell us:
It seems that many units use the RUNIT clock.
SPI, UART, NAND, TWSI, ...
So it's not possible to clock gate it.
Currently the SPI, NAND and TWSI driver will clk_prepaure_enable()
this clk, but since we have no idea what ... is, and turning this clk
off results in a hard lock, unconditionally enable runit.
Thus, if we know better than that, that's fine, but please don't tell
me that this is "blindly" enabling clocks.
>
> >Thus, we should keep it enabled even if it is unused, which is
> >exactly the purpose of CLK_IGNORE_UNUSED if I understood this
> >correctly.
>
> True, but only if it is that important that it should _never_ be gated.
> As long as it is 'only' used by peripheral devices, it should be safe
> to gate it.
>
> >>Could you also please try kirkwood_defconfig and tell us if it boots?
> >
> >It is very easy to get my system to boot with a stock kernel. Just
> >build one of the drivers I use directly into the kernel and it boots
> >(up to the point where the gbe driver is loaded if built as a module,
> >of course).
> >
> >>>Here are my findings with various patches: ("non-DT" means booting
> >>>the IBNAS6210 with machine ID 1680 ???Marvell DB-88F6281-BP
> >>>Development Board???, which works reasonably well)
> >>>
> >>>3.8-rc5 + runit patch:
> >>>
> >>>DT: Hangs at boot (when loading mv643xx_eth)
> >>>non-DT: Boots ok
> >
> >In the DT case ge0 and ge1 are NULL, and thus, kirkwood_ge0[01]_init()
> >tries to enable NULL clocks, but not the gbe clocks. -> The clocks
> >get disabled.
> >
> >As described in Sebastian's patch (and also found by Andrew some time
> >ago), this leads to a hanging system when loading the gbe driver.
>
> If I got all your configs right, this DT case is with serial but no
> clocks property? All other runit "users" are _not_ built into the
> kernel? Maybe it is just a coincidence that it fails when loading
> eth but I guess it hangs because of runit getting gated while serial
> accessing it. When you replace serial's clock-frequency with clocks
> property to "runit" it shouldn't hang.
No, this is the SMI hang already. As stated its "3.8-rc5 + runit
patch". So runit is running.
And sure, removing "clock-frequency" gets the kernel booting until
the gbe driver loads, as I said above in the same mail.
> (Issue 1: gated runit clock hangs kernel due to serial access)
Yes, and issue 1a: gated runit clock hangs kernel due to "...".
I can't get a stock kernel to boot when additionally disabling the
serial driver altogether (and compiling the Ethernet driver into the
kernel to avoid its lockup).
When the runit clock is enabled all the time, it works. I have no
idea where it gets stuck, since I have no console. It looks like the
SATA module does something (telling from the LEDs), but booting does
not continue.
So, we have a statement from Marvell not to gate it, we know that it
is needed for "...", can we please not gate it?
>
> >>>3.8-rc5 + runit patch + ge00/ge01 patch:
> >>>
> >>>DT: Boots ok
> >>>non-DT: Boots ok
> >
> >Since the clocks are found now and kept enabled, DT behaves the same
> >as non-DT.
> >
> >>>
> >>>3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
> >>>legacy clock names):
> >>>
> >>>DT: Boots, but no MAC
> >>>non-DT: Boots ok
> >
> >This is the behavior originally found by Andrew. The clock patch
> >eliminates the lockup, but the hardware forgets its MAC address.
> >
> >>>
> >>>3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
> >>>load:
> >>>
> >>>DT: Boots, but no MAC
> >>>non-DT: Boots, but no MAC
>
> Ok, here my patch for smi clock enables gbe clock before accessing gbe
> registers.
>
> (Issue 2: gated gbe clock hangs kernel due to smi access)
>
> >I think non-DT and DT gated clocks behave differently, since the
> >non-DT ones also enable/disable the PHY. I explicitly removed the
> >clk_prepare_enable() from kirkwood_ge0[01]_init() in order to see if
> >this makes a difference.
>
> True, DT gated clocks don't disable PHYs (and never will).
>
> >(Which reminds me, that we wanted to implement the PHY enabling in
> >the driver.)
> >
> >Apparently, it does not make a difference.
>
> Leaves Issue 3, gbe forgets about its MAC address when gated or powered
> down. That should be done with local-mac-address passed by DT enabled
> u-boot or any other (dirty) ATAG hack ;)
Fine with all of that. But: I am talking about 3.8 all the time. We
have three options for issues 2 and 3 from my point of view:
1. We do proper fixes in 3.8 for issues 2 and 3.
2. We fix this regression by not gating the clock in both the DT and
the non-DT case, preferably by using the correct clocks in
kirkwood_ge0[01]_init(). Additionally, Jason promises that all gets
well with the DT aware driver in 3.9. ;-)
3. Do nothing. Simply accept that we broke modular Ethernet for DT
because some code relies on two pointers being set. When we
introduced a new code path for DT, we forgot about these pointers.
Bad luck, the solution was not nice anyway and we will do proper
fixes in 3.9.
As should be clear by now, I think we should go for option 2.
- Simon
^ permalink raw reply
* [PATCH v3 2/3] ARM: static_vm: introduce an infrastructure for static mapped area
From: Nicolas Pitre @ 2013-01-30 0:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358990934-4893-3-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, 24 Jan 2013, Joonsoo Kim wrote:
> From: Joonsoo Kim <js1304@gmail.com>
>
> In current implementation, we used ARM-specific flag, that is,
> VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
> The purpose of static mapped area is to re-use static mapped area when
> entire physical address range of the ioremap request can be covered
> by this area.
>
> This implementation causes needless overhead for some cases.
> For example, assume that there is only one static mapped area and
> vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
> deciding whether it is matched or not. Moreover, even if there is
> no static mapped area and vmlist has 300 areas, every time we call
> ioremap, we check 300 areas in now.
>
> If we construct a extra list for static mapped area, we can eliminate
> above mentioned overhead.
> With a extra list, if there is one static mapped area,
> we just check only one area and proceed next operation quickly.
>
> In fact, it is not a critical problem, because ioremap is not frequently
> used. But reducing overhead is better idea.
>
> Another reason for doing this work is for removing architecture dependency
> on vmalloc layer. I think that vmlist and vmlist_lock is internal data
> structure for vmalloc layer. Some codes for debugging and stat inevitably
> use vmlist and vmlist_lock. But it is preferable that they are used
> as least as possible in outside of vmalloc.c
>
> Now, I introduce an ARM-specific infrastructure for static mapped area. In
> the following patch, we will use this and resolve above mentioned problem.
>
> Signed-off-by: Joonsoo Kim <js1304@gmail.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
First of all, I don't think you really need a new file with a global
scope header file. Given that this code is meant to be used only for
ioremap optimization on ARM, it is probably a better idea to simply put
it all into arch/arm/mm/ioremap.c instead. The only function that needs
to be exported out of ioremap.c is insert_static_vm(), and only for the
benefit of arch/arm/mm/mmu.c, therefore this function prototype may as
well just be added to arch/arm/mm/mm.h.
More comments below.
> diff --git a/arch/arm/include/asm/mach/static_vm.h b/arch/arm/include/asm/mach/static_vm.h
> new file mode 100644
> index 0000000..72c8339
> --- /dev/null
> +++ b/arch/arm/include/asm/mach/static_vm.h
> @@ -0,0 +1,45 @@
> +/*
> + * arch/arm/include/asm/mach/static_vm.h
> + *
> + * Copyright (C) 2012 LG Electronics, Joonsoo Kim <iamjoonsoo.kim@lge.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef _ASM_MACH_STATIC_VM_H
> +#define _ASM_MACH_STATIC_VM_H
> +
> +#include <linux/types.h>
> +#include <linux/vmalloc.h>
> +
> +struct static_vm {
> + struct static_vm *next;
> + void *vaddr;
> + unsigned long size;
> + unsigned long flags;
> + phys_addr_t paddr;
> + const void *caller;
> +};
Here you're duplicating most of the vm_struct content for no obvious
reasons. Patch #3 even allocates both a vm_struct and a static_vm
instance in parallel for each mapping. Instead, you should consider
something like this:
struct static_vm {
struct static_vm *next;
struct vm_struct vm;
};
This way, you only need to allocate one structure:
struct static_vm *svm = early_alloc(...);
...
svm->vm.addr = addr;
...
vm_area_add_early(&svm->vm);
insert_static_vm(svm);
And then, it would make sense for the insert_static_vm() to do the
vm_area_add_early() call itself as well.
Maybe rename insert_static_vm() to static_vm_area_add_early() to better
identify its purpose as well. It shouldn't be used for any other
purpose anyway.
> +
> +extern struct static_vm *static_vmlist;
> +extern spinlock_t static_vmlist_lock;
Your patch is providing the proper accessors to manipulate those. They
therefore should not be exported globally.
> +
> +extern struct static_vm *find_static_vm_paddr(phys_addr_t paddr,
> + size_t size, unsigned long flags);
> +extern struct static_vm *find_static_vm_vaddr(void *vaddr);
> +extern void init_static_vm(struct static_vm *static_vm,
> + struct vm_struct *vm, unsigned long flags);
Since those are only used in ioremap.c, and because I suggested their
implementation be moved there as well, you shouldn't need prototype
declarations anymore. And init_static_vm() would be useless with my
previous suggestions.
Nicolas
^ permalink raw reply
* [PATCH v3 3/3] ARM: mm: use static_vm for managing static mapped areas
From: Nicolas Pitre @ 2013-01-30 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358990934-4893-4-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, 24 Jan 2013, Joonsoo Kim wrote:
> From: Joonsoo Kim <js1304@gmail.com>
>
> A static mapped area is ARM-specific, so it is better not to use
> generic vmalloc data structure, that is, vmlist and vmlist_lock
> for managing static mapped area. And it causes some needless overhead and
> reducing this overhead is better idea.
>
> Now, we have newly introduced static_vm infrastructure.
> With it, we don't need to iterate all mapped areas. Instead, we just
> iterate static mapped areas. It helps to reduce an overhead of finding
> matched area. And architecture dependency on vmalloc layer is removed,
> so it will help to maintainability for vmalloc layer.
>
> Signed-off-by: Joonsoo Kim <js1304@gmail.com>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Given my comments to patch #2, the content of this patch should be
reworked accordingly.
>
> diff --git a/arch/arm/include/asm/mach/static_vm.h b/arch/arm/include/asm/mach/static_vm.h
> index 72c8339..24672b1 100644
> --- a/arch/arm/include/asm/mach/static_vm.h
> +++ b/arch/arm/include/asm/mach/static_vm.h
> @@ -32,6 +32,12 @@ struct static_vm {
> const void *caller;
> };
>
> +#define STATIC_VM_MEM 0x00000001
> +#define STATIC_VM_EMPTY 0x00000002
> +
> +/* mtype should be less than 28 */
> +#define STATIC_VM_MTYPE(mt) (1UL << ((mt) + 4))
> +
> extern struct static_vm *static_vmlist;
> extern spinlock_t static_vmlist_lock;
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 88fd86c..2c0d3a1 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -36,6 +36,7 @@
> #include <asm/system_info.h>
>
> #include <asm/mach/map.h>
> +#include <asm/mach/static_vm.h>
> #include <asm/mach/pci.h>
> #include "mm.h"
>
> @@ -197,7 +198,8 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> const struct mem_type *type;
> int err;
> unsigned long addr;
> - struct vm_struct * area;
> + struct vm_struct *area;
> + phys_addr_t paddr = __pfn_to_phys(pfn);
>
> #ifndef CONFIG_ARM_LPAE
> /*
> @@ -219,24 +221,17 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> /*
> * Try to reuse one of the static mapping whenever possible.
> */
> - read_lock(&vmlist_lock);
> - for (area = vmlist; area; area = area->next) {
> - if (!size || (sizeof(phys_addr_t) == 4 && pfn >= 0x100000))
> - break;
> - if (!(area->flags & VM_ARM_STATIC_MAPPING))
> - continue;
> - if ((area->flags & VM_ARM_MTYPE_MASK) != VM_ARM_MTYPE(mtype))
> - continue;
> - if (__phys_to_pfn(area->phys_addr) > pfn ||
> - __pfn_to_phys(pfn) + size-1 > area->phys_addr + area->size-1)
> - continue;
> - /* we can drop the lock here as we know *area is static */
> - read_unlock(&vmlist_lock);
> - addr = (unsigned long)area->addr;
> - addr += __pfn_to_phys(pfn) - area->phys_addr;
> - return (void __iomem *) (offset + addr);
> + if (size && !((sizeof(phys_addr_t) == 4 && pfn >= 0x100000))) {
> + struct static_vm *static_vm;
> +
> + static_vm = find_static_vm_paddr(__pfn_to_phys(pfn), size,
> + STATIC_VM_MEM | STATIC_VM_MTYPE(mtype));
> + if (static_vm) {
> + addr = (unsigned long)static_vm->vaddr;
> + addr += paddr - static_vm->paddr;
> + return (void __iomem *) (offset + addr);
> + }
> }
> - read_unlock(&vmlist_lock);
>
> /*
> * Don't allow RAM to be mapped - this causes problems with ARMv6+
> @@ -248,7 +243,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> if (!area)
> return NULL;
> addr = (unsigned long)area->addr;
> - area->phys_addr = __pfn_to_phys(pfn);
> + area->phys_addr = paddr;
>
> #if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
> if (DOMAIN_IO == 0 &&
> @@ -346,34 +341,20 @@ __arm_ioremap_exec(unsigned long phys_addr, size_t size, bool cached)
> void __iounmap(volatile void __iomem *io_addr)
> {
> void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
> - struct vm_struct *vm;
> -
> - read_lock(&vmlist_lock);
> - for (vm = vmlist; vm; vm = vm->next) {
> - if (vm->addr > addr)
> - break;
> - if (!(vm->flags & VM_IOREMAP))
> - continue;
> - /* If this is a static mapping we must leave it alone */
> - if ((vm->flags & VM_ARM_STATIC_MAPPING) &&
> - (vm->addr <= addr) && (vm->addr + vm->size > addr)) {
> - read_unlock(&vmlist_lock);
> - return;
> - }
> + struct static_vm *static_vm;
> +
> + static_vm = find_static_vm_vaddr(addr);
> + if (static_vm)
> + return;
> +
> #if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
> - /*
> - * If this is a section based mapping we need to handle it
> - * specially as the VM subsystem does not know how to handle
> - * such a beast.
> - */
> - if ((vm->addr == addr) &&
> - (vm->flags & VM_ARM_SECTION_MAPPING)) {
> + {
> + struct vm_struct *vm;
> + vm = find_vm_area(addr);
> + if (vm && (vm->flags & VM_ARM_SECTION_MAPPING))
> unmap_area_sections((unsigned long)vm->addr, vm->size);
> - break;
> - }
> -#endif
> }
> - read_unlock(&vmlist_lock);
> +#endif
>
> vunmap(addr);
> }
> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
> index a8ee92d..3ae75e5 100644
> --- a/arch/arm/mm/mm.h
> +++ b/arch/arm/mm/mm.h
> @@ -52,16 +52,6 @@ extern void __flush_dcache_page(struct address_space *mapping, struct page *page
> /* (super)section-mapped I/O regions used by ioremap()/iounmap() */
> #define VM_ARM_SECTION_MAPPING 0x80000000
>
> -/* permanent static mappings from iotable_init() */
> -#define VM_ARM_STATIC_MAPPING 0x40000000
> -
> -/* empty mapping */
> -#define VM_ARM_EMPTY_MAPPING 0x20000000
> -
> -/* mapping type (attributes) for permanent static mappings */
> -#define VM_ARM_MTYPE(mt) ((mt) << 20)
> -#define VM_ARM_MTYPE_MASK (0x1f << 20)
> -
> /* consistent regions used by dma_alloc_attrs() */
> #define VM_ARM_DMA_CONSISTENT 0x20000000
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 9f06102..b799b69 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -31,6 +31,7 @@
>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> +#include <asm/mach/static_vm.h>
> #include <asm/mach/pci.h>
>
> #include "mm.h"
> @@ -757,21 +758,28 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
> {
> struct map_desc *md;
> struct vm_struct *vm;
> + struct static_vm *static_vm;
>
> if (!nr)
> return;
>
> vm = early_alloc_aligned(sizeof(*vm) * nr, __alignof__(*vm));
> + static_vm = early_alloc_aligned(sizeof(*static_vm) * nr,
> + __alignof__(*static_vm));
>
> for (md = io_desc; nr; md++, nr--) {
> create_mapping(md);
> +
> vm->addr = (void *)(md->virtual & PAGE_MASK);
> vm->size = PAGE_ALIGN(md->length + (md->virtual & ~PAGE_MASK));
> vm->phys_addr = __pfn_to_phys(md->pfn);
> - vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
> - vm->flags |= VM_ARM_MTYPE(md->type);
> + vm->flags = VM_IOREMAP;
> vm->caller = iotable_init;
> +
> + init_static_vm(static_vm, vm, STATIC_VM_MEM |
> + STATIC_VM_MTYPE(md->type));
> vm_area_add_early(vm++);
> + insert_static_vm(static_vm++);
> }
> }
>
> @@ -779,13 +787,20 @@ void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
> void *caller)
> {
> struct vm_struct *vm;
> + struct static_vm *static_vm;
>
> vm = early_alloc_aligned(sizeof(*vm), __alignof__(*vm));
> + static_vm = early_alloc_aligned(sizeof(*static_vm),
> + __alignof__(*static_vm));
> +
> vm->addr = (void *)addr;
> vm->size = size;
> - vm->flags = VM_IOREMAP | VM_ARM_EMPTY_MAPPING;
> + vm->flags = VM_IOREMAP;
> vm->caller = caller;
> +
> + init_static_vm(static_vm, vm, STATIC_VM_EMPTY);
> vm_area_add_early(vm);
> + insert_static_vm(static_vm);
> }
>
> #ifndef CONFIG_ARM_LPAE
> @@ -810,15 +825,19 @@ static void __init pmd_empty_section_gap(unsigned long addr)
>
> static void __init fill_pmd_gaps(void)
> {
> - struct vm_struct *vm;
> + struct static_vm *area;
> unsigned long addr, next = 0;
> pmd_t *pmd;
>
> - /* we're still single threaded hence no lock needed here */
> - for (vm = vmlist; vm; vm = vm->next) {
> - if (!(vm->flags & (VM_ARM_STATIC_MAPPING | VM_ARM_EMPTY_MAPPING)))
> - continue;
> - addr = (unsigned long)vm->addr;
> + /*
> + * We should not take a lock here, because pmd_empty_section_gap()
> + * invokes vm_reserve_area_early(), and then it call insert_static_vm()
> + * which try to take a lock.
> + * We're still single thread, so traverse whole list without a lock
> + * is safe for now. And inserting new entry is also safe.
> + */
> + for (area = static_vmlist; area; area = area->next) {
> + addr = (unsigned long)area->vaddr;
> if (addr < next)
> continue;
>
> @@ -838,7 +857,7 @@ static void __init fill_pmd_gaps(void)
> * If so and the second section entry for this PMD is empty
> * then we block the corresponding virtual address.
> */
> - addr += vm->size;
> + addr += area->size;
> if ((addr & ~PMD_MASK) == SECTION_SIZE) {
> pmd = pmd_off_k(addr) + 1;
> if (pmd_none(*pmd))
> @@ -857,19 +876,12 @@ static void __init fill_pmd_gaps(void)
> #if defined(CONFIG_PCI) && !defined(CONFIG_NEED_MACH_IO_H)
> static void __init pci_reserve_io(void)
> {
> - struct vm_struct *vm;
> - unsigned long addr;
> + struct static_vm *static_vm;
>
> - /* we're still single threaded hence no lock needed here */
> - for (vm = vmlist; vm; vm = vm->next) {
> - if (!(vm->flags & VM_ARM_STATIC_MAPPING))
> - continue;
> - addr = (unsigned long)vm->addr;
> - addr &= ~(SZ_2M - 1);
> - if (addr == PCI_IO_VIRT_BASE)
> - return;
> + static_vm = find_static_vm_vaddr((void *)PCI_IO_VIRT_BASE);
> + if (static_vm)
> + return;
>
> - }
> vm_reserve_area_early(PCI_IO_VIRT_BASE, SZ_2M, pci_reserve_io);
> }
> #else
> --
> 1.7.9.5
>
^ permalink raw reply
* ixp4xx eth broken in 3.7.0/3.8-rc5?
From: Mikael Pettersson @ 2013-01-30 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20744.9777.937924.822371@pilspetsen.it.uu.se>
Mikael Pettersson writes:
> When I try to update my ixp4xx machine to a 3.8-rc5 kernel it boots
> Ok but the network (CONFIG_IXP4XX_ETH=y) fails to come up, with the
> following in the kernel log:
>
> net eth0: coherent DMA mask is unset
>
> With a 3.7.0 kernel the situation is similar, except that the "net
> eth0: coherent DMA mask is unset" message repeats itself endlessly
> and I can't even get in on the serial console.
>
> With the 3.6.0 kernel everything works perfectly.
A git bisect identified the following as the culprit:
> From 1a4901177574083c35fafc24c4d151c2a7c7647c Mon Sep 17 00:00:00 2001
> From: Xi Wang <xi.wang@gmail.com>
> Date: Sat, 17 Nov 2012 20:25:09 +0000
> Subject: [PATCH] ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
>
> Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
> allow NULL dev.
>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/xscale/ixp4xx_eth.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
Reverting this unbreaks ixp4xx_eth on my ixp4xx machine with kernels
3.7.0 and 3.8-rc5.
(Added cc: author and netdev.)
/Mikael
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Nicolas Pitre @ 2013-01-30 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129231205.GA25176@MacBook-Pro.local>
On Tue, 29 Jan 2013, Catalin Marinas wrote:
> On Tue, Jan 29, 2013 at 10:35:46PM +0000, Nicolas Pitre wrote:
> > On Tue, 29 Jan 2013, Catalin Marinas wrote:
> >
> > > All the calls to gic_secondary_init() pass 0 as the first argument.
> > > Since this function is called on each CPU when starting, it can be done
> > > in a platform-independent way via a CPU notifier registered by the GIC
> > > code.
> > >
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Acked-by: Stephen Warren <swarren@nvidia.com>
> > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > > Acked-by: Rob Herring <rob.herring@calxeda.com>
> > > Acked-by: Simon Horman <horms+renesas@verge.net.au>
> > > Tested-by: Simon Horman <horms+renesas@verge.net.au>
> > > Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Kukjin Kim <kgene.kim@samsung.com>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: David Brown <davidb@codeaurora.org>
> > > Cc: Bryan Huntsman <bryanh@codeaurora.org>
> > > Cc: Tony Lindgren <tony@atomide.com>
> > > Cc: Magnus Damm <magnus.damm@gmail.com>
> > > Cc: Dinh Nguyen <dinguyen@altera.com>
> > > Cc: Shiraz Hashim <shiraz.hashim@st.com>
> > > Cc: Linus Walleij <linus.walleij@linaro.org>
> >
> > Acked-by: Nicolas Pitre <nico@linaro.org>
>
> Thanks.
>
> > What is your plan in terms of merge path and schedule? My mcpm series
> > would depend on this.
>
> I would like to get them in as soon as possible (ideally 3.9) as AArch64
> needs GIC support. I can base them on Rob's branch (already in -next)
> and send them the same route (the arm-soc tree if Olof/Arnd are ok to
> take them).
Well... I'd prefer if my series was merged by RMK since this is mostly
core ARM code. That is posing dependency issues.
I think I'll just ignore your change for now and we'll fix things up
during the v3.9-rc period.
Nicolas
^ permalink raw reply
* [GIT PULL] ux500 <mach/id.h> removal
From: Olof Johansson @ 2013-01-30 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY9BDyGQ-DiEhTiyHEYoxpGiL+H0baqsBYX_a-0upktUQ@mail.gmail.com>
Hi,
On Tue, Jan 29, 2013 at 10:06 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> Hi ARM SoC maintainers,
>
> This patch set removes the use of <mach/id.h> from being broadcasted across
> the kernel and blocks any further usage of cpu_is* outside of the machine.
>
> Target is v3.9 cleanups.
>
> It is part of our path toward single zImage.
>
> Please pull it in! Detailed description in the tag, MFD hunk ACKed by
> Samuel Ortiz.
>
> Yours,
> Linus Walleij
>
> The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
>
> Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> tags/ux500-no-idh
Pulled in.
This has a somewhat annoying (but trivial) conflict against your own
code (the cpufreq driver changes).
-Olof
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Dinh Nguyen @ 2013-01-30 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359476319-23720-5-git-send-email-catalin.marinas@arm.com>
Hi Catalina,
On Tue, 2013-01-29 at 16:18 +0000, Catalin Marinas wrote:
> All the calls to gic_secondary_init() pass 0 as the first argument.
> Since this function is called on each CPU when starting, it can be done
> in a platform-independent way via a CPU notifier registered by the GIC
> code.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> Tested-by: Simon Horman <horms+renesas@verge.net.au>
> Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: David Brown <davidb@codeaurora.org>
> Cc: Bryan Huntsman <bryanh@codeaurora.org>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Dinh Nguyen <dinguyen@altera.com>
> Cc: Shiraz Hashim <shiraz.hashim@st.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/mach-exynos/platsmp.c | 8 --------
> arch/arm/mach-highbank/platsmp.c | 7 -------
> arch/arm/mach-imx/platsmp.c | 12 ------------
> arch/arm/mach-msm/platsmp.c | 8 --------
> arch/arm/mach-omap2/omap-smp.c | 7 -------
> arch/arm/mach-shmobile/smp-emev2.c | 7 -------
> arch/arm/mach-shmobile/smp-r8a7779.c | 7 -------
> arch/arm/mach-shmobile/smp-sh73a0.c | 7 -------
> arch/arm/mach-socfpga/platsmp.c | 12 ------------
> arch/arm/mach-spear13xx/platsmp.c | 8 --------
> arch/arm/mach-tegra/platsmp.c | 8 --------
> arch/arm/mach-ux500/platsmp.c | 8 --------
> arch/arm/plat-versatile/platsmp.c | 8 --------
> drivers/irqchip/irq-gic.c | 28 +++++++++++++++++++++-------
> include/linux/irqchip/arm-gic.h | 1 -
> 15 files changed, 21 insertions(+), 115 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index a083e05..a0e8ff7 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -20,7 +20,6 @@
> #include <linux/jiffies.h>
> #include <linux/smp.h>
>
For mach-socfpga:
Tested-by: Dinh Nguyen <dinguyen@altera.com>
Thanks,
Dinh
^ permalink raw reply
* ixp4xx eth broken in 3.7.0/3.8-rc5?
From: Xi Wang @ 2013-01-30 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20744.25884.660535.514911@pilspetsen.it.uu.se>
On 1/29/13 7:11 PM, Mikael Pettersson wrote:
> A git bisect identified the following as the culprit:
>
> > From 1a4901177574083c35fafc24c4d151c2a7c7647c Mon Sep 17 00:00:00 2001
> > From: Xi Wang <xi.wang@gmail.com>
> > Date: Sat, 17 Nov 2012 20:25:09 +0000
> > Subject: [PATCH] ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
> >
> > Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
> > allow NULL dev.
> >
> > Signed-off-by: Xi Wang <xi.wang@gmail.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > ---
> > drivers/net/ethernet/xscale/ixp4xx_eth.c | 8 +++++---
> > 1 files changed, 5 insertions(+), 3 deletions(-)
>
> Reverting this unbreaks ixp4xx_eth on my ixp4xx machine with kernels
> 3.7.0 and 3.8-rc5.
Thanks. The problem was that in init_queues(), the dma_pool_create()
call requires a non-null dev.
dma_pool = dma_pool_create(DRV_NAME, ??, ...);
What do you think would work here?
^ permalink raw reply
* [RFC PATCH v2 0/2] ARM: update cpuinfo to print SoC model name
From: Ruslan Bilovol @ 2013-01-30 0:38 UTC (permalink / raw)
To: linux-arm-kernel
The following patches update cpuinfo to print SoC
model name for ARM.
The first patch exactly makes needed changes for ARM
architecture and adds a common approach to show SoC name.
Second patch uses this approach for OMAP4 SoCs (as live
example).
Looks like there were few attempts to do similar
changes to cpuinfo without any luck (had stuck
on review) so this functionality is still not
in the kernel yet.
In this patch series the update to cpuinfo is very
short (10 lines) and easy.
Comments are welcome as usual
--------------------------------------------------
v2:
Addressed comments from Russel (changed 'CPU name' > 'SoC name')
Updatet commit messages. Updated cover letter
Ruslan Bilovol (2):
ARM: kernel: update cpuinfo to print SoC model name
ARM: OMAP4: setup SoC model name during ID initialisation
arch/arm/include/asm/setup.h | 1 +
arch/arm/kernel/setup.c | 9 +++++++++
arch/arm/mach-omap2/id.c | 18 ++++++++++++++++--
3 files changed, 26 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RFC PATCH v2 1/2] ARM: kernel: update cpuinfo to print SoC model name
From: Ruslan Bilovol @ 2013-01-30 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359506337-21619-1-git-send-email-ruslan.bilovol@ti.com>
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace using this information may decide what module
to load or how to configure some specific (and processor-depended)
settings or so.
However, since really different SoCs can share same ARM core,
this information currently is not so useful.
For example, TI OMAP4460 and OMAP4470 SoCs show the same
information in the /proc/cpuinfo whereas they are different.
Since in most cases ARM CPU is a part of some system on a chip (SoC),
the "cpuinfo" file looks like exactly that place, where this
information have to be displayed.
So added new line "SoC name" in the "cpuinfo" output for system
on a chip name. It is placed between CPU information and machine
information, so the file structure looks gracefully (CPU-SoC-Hardware)
Example:
/ # cat proc/cpuinfo
[...]
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
SoC name : OMAP4470 ES1.0 HS
Hardware : OMAP4 Blaze Tablet
Revision : 20edb4
[...]
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
---
arch/arm/include/asm/setup.h | 1 +
arch/arm/kernel/setup.c | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index c50f056..621df40 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -52,5 +52,6 @@ extern struct meminfo meminfo;
extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
extern void early_print(const char *str, ...);
extern void dump_machine_table(void);
+extern void set_soc_model_name(char *name);
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..bb3805f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -134,6 +134,7 @@ char elf_platform[ELF_PLATFORM_SIZE];
EXPORT_SYMBOL(elf_platform);
static const char *cpu_name;
+static const char *soc_name;
static const char *machine_name;
static char __initdata cmd_line[COMMAND_LINE_SIZE];
struct machine_desc *machine_desc __initdata;
@@ -493,6 +494,11 @@ static void __init setup_processor(void)
cpu_init();
}
+void set_soc_model_name(char *name)
+{
+ soc_name = name;
+}
+
void __init dump_machine_table(void)
{
struct machine_desc *p;
@@ -902,6 +908,9 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
}
+ if (soc_name)
+ seq_printf(m, "SoC name\t: %s\n\n", soc_name);
+
seq_printf(m, "Hardware\t: %s\n", machine_name);
seq_printf(m, "Revision\t: %04x\n", system_rev);
seq_printf(m, "Serial\t\t: %08x%08x\n",
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v2 2/2] ARM: OMAP4: setup SoC model name during ID initialisation
From: Ruslan Bilovol @ 2013-01-30 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359506337-21619-1-git-send-email-ruslan.bilovol@ti.com>
Set up the SoC model name during OMAP ID initialisation
so it will be displayed in /proc/cpuinfo:
/ # cat proc/cpuinfo
[...]
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
SoC name : OMAP4470 ES1.0 HS
Hardware : OMAP4 Blaze Tablet
Revision : 20edb4
[...]
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
---
arch/arm/mach-omap2/id.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 45cc7ed4..b1fba35 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -20,6 +20,7 @@
#include <linux/io.h>
#include <asm/cputype.h>
+#include <asm/setup.h>
#include "common.h"
@@ -33,8 +34,17 @@
static unsigned int omap_revision;
static const char *cpu_rev;
+static char omap_soc_model_name[80];
u32 omap_features;
+static const char const *omap_types[] = {
+ [OMAP2_DEVICE_TYPE_TEST] = "TST",
+ [OMAP2_DEVICE_TYPE_EMU] = "EMU",
+ [OMAP2_DEVICE_TYPE_SEC] = "HS",
+ [OMAP2_DEVICE_TYPE_GP] = "GP",
+ [OMAP2_DEVICE_TYPE_BAD] = "BAD",
+};
+
unsigned int omap_rev(void)
{
return omap_revision;
@@ -502,8 +512,12 @@ void __init omap4xxx_check_revision(void)
omap_revision = OMAP4430_REV_ES2_3;
}
- pr_info("OMAP%04x ES%d.%d\n", omap_rev() >> 16,
- ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf));
+ sprintf(omap_soc_model_name, "OMAP%04x ES%d.%d %s", omap_rev() >> 16,
+ ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf),
+ omap_types[omap_type()]);
+ set_soc_model_name(omap_soc_model_name);
+
+ pr_info("%s\n", omap_soc_model_name);
}
void __init omap5xxx_check_revision(void)
--
1.7.9.5
^ permalink raw reply related
* [arm-soc:next/soc 4/8] arch/arm/mach-prima2/platsmp.c:20:30: fatal error: asm/hardware/gic.h: No such file or directory
From: Olof Johansson @ 2013-01-30 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130002905.GA55457@bee>
On Wed, Jan 30, 2013 at 08:29:05AM +0800, Xie ChanglongX wrote:
>
> Hi Olof,
>
> FYI, kernel build failed on
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git next/soc
> head: 6ed05a2aab3763b58922247543d7079106b254dc
> commit: af70fdc947dbe835acc26c6ee9e8e930f38935f8 [4/8] Merge branch 'marco-timer-cleanup-rebase' of git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel into next/soc
> config: make ARCH=arm prima2_defconfig
Thanks! Yes, this is a known issue as of this morning, I didn't catch it before
I merged in so I asked Barry to follow up with a fix.
-Olof
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-30 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130000341.GA10600@schnuecks.de>
On 01/30/2013 01:03 AM, Simon Baatz wrote:
> On Tue, Jan 29, 2013 at 09:08:46PM +0100, Sebastian Hesselbarth wrote:
>> Well, if there is no device/driver using runit it should be safe to disable
>> it. If there is a driver using it, we need a clocks property for it. And
>> as you already stated, serial is using it. And you want serial in every
>> minimal kernel, don't you?
>
> From f479db4:
>
> Marvell engineers tell us:
>
> It seems that many units use the RUNIT clock.
> SPI, UART, NAND, TWSI, ...
> So it's not possible to clock gate it.
>
> Currently the SPI, NAND and TWSI driver will clk_prepaure_enable()
> this clk, but since we have no idea what ... is, and turning this clk
> off results in a hard lock, unconditionally enable runit.
>
>
> Thus, if we know better than that, that's fine, but please don't tell
> me that this is "blindly" enabling clocks.
Hmm, should have seen that comment ealier. Based on your/Andrew's statement
above using CLK_IGNORE_UNUSED on runit maybe is the best.
So I guess we take patch 2/2 and extend DT clock gating for .flags later?
> So, we have a statement from Marvell not to gate it, we know that it
> is needed for "...", can we please not gate it?
Ack.
>>>>> 3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
>>>>> legacy clock names):
>>>>>
>>>>> DT: Boots, but no MAC
>>>>> non-DT: Boots ok
>>>
>>> This is the behavior originally found by Andrew. The clock patch
>>> eliminates the lockup, but the hardware forgets its MAC address.
For the smi clock issue: DT is fixed by the smi clock patch, right?
non-DT should be fixed in kirkwood_clk_init() with an orion_clkdev_add()
alias for MV643XX_ETH_SHARED_NAME ".0" and ".1" respectively.
For the MAC address issue: non-DT doesn't need to be fixed, right?
DT clock gates should be fixed in kirkwood_legacy_clk_init which will
also save the clk_get_sys() call. We can easily remove it when mv643xx_eth
catches the MAC address from either local-mac-address or ATAG.
> Fine with all of that. But: I am talking about 3.8 all the time. We
> have three options for issues 2 and 3 from my point of view:
>
> 1. We do proper fixes in 3.8 for issues 2 and 3.
>
> 2. We fix this regression by not gating the clock in both the DT and
> the non-DT case, preferably by using the correct clocks in
> kirkwood_ge0[01]_init(). Additionally, Jason promises that all gets
> well with the DT aware driver in 3.9. ;-)
>
> 3. Do nothing. Simply accept that we broke modular Ethernet for DT
> because some code relies on two pointers being set. When we
> introduced a new code path for DT, we forgot about these pointers.
> Bad luck, the solution was not nice anyway and we will do proper
> fixes in 3.9.
>
> As should be clear by now, I think we should go for option 2.
Agreed, do you think all issues you are suffering will be solved with:
- [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
(no lockup for minimal kernel configs)
- [PATCH] NET: mv643xx: get smi clock from device tree
(no lockup for modular DT ethernet)
- Some patch that adds MV643XX_ETH_SHARED_NAME ".0" and ".1" clk aliases
(no lockup for modular non-DT ethernet)
- Some patch that adds clk_prepare_enable to ge0/ge1 clocks to
kirkwood_legacy_clk_init()
(retain MAC address for modular DT ethernet)
I'll prepare the latter patches and post them.
Sebastian
^ permalink raw reply
* [PATCH] rtc: pl031: fix the missing operation on enable
From: Haojian Zhuang @ 2013-01-30 1:04 UTC (permalink / raw)
To: linux-arm-kernel
RTC control register should be enabled in the process of initliazing.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
---
drivers/rtc/rtc-pl031.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 08378e3..10c1a34 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -44,6 +44,7 @@
#define RTC_YMR 0x34 /* Year match register */
#define RTC_YLR 0x38 /* Year data load register */
+#define RTC_CR_EN (1 << 0) /* counter enable bit */
#define RTC_CR_CWEN (1 << 26) /* Clockwatch enable bit */
#define RTC_TCR_EN (1 << 1) /* Periodic timer enable bit */
@@ -320,7 +321,7 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
struct pl031_local *ldata;
struct pl031_vendor_data *vendor = id->data;
struct rtc_class_ops *ops = &vendor->ops;
- unsigned long time;
+ unsigned long time, data;
ret = amba_request_regions(adev, NULL);
if (ret)
@@ -345,10 +346,11 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
dev_dbg(&adev->dev, "designer ID = 0x%02x\n", amba_manf(adev));
dev_dbg(&adev->dev, "revision = 0x%01x\n", amba_rev(adev));
+ data = readl(ldata->base + RTC_CR);
/* Enable the clockwatch on ST Variants */
if (vendor->clockwatch)
- writel(readl(ldata->base + RTC_CR) | RTC_CR_CWEN,
- ldata->base + RTC_CR);
+ data |= RTC_CR_CWEN;
+ writel(data | RTC_CR_EN, ldata->base + RTC_CR);
/*
* On ST PL031 variants, the RTC reset value does not provide correct
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] arm: fix returning wrong CALLER_ADDRx
From: kpark3469 at gmail.com @ 2013-01-30 1:20 UTC (permalink / raw)
To: linux-arm-kernel
From: sahara <keun-o.park@windriver.com>
This makes return_address return correct value for ftrace feature.
unwind_frame does not update frame->lr but frame->pc for backtrace.
And, the initialization for data.addr was missing so that wrong value
returned when unwind_frame failed.
Signed-off-by: Sahara <keun-o.park@windriver.com>
Reviewed-by: Dave Martin <dave.martin@linaro.org>
---
arch/arm/kernel/return_address.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..fafedd8 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
struct return_address_data *data = d;
if (!data->level) {
- data->addr = (void *)frame->lr;
+ data->addr = (void *)frame->pc;
return 1;
} else {
@@ -41,7 +41,8 @@ void *return_address(unsigned int level)
struct stackframe frame;
register unsigned long current_sp asm ("sp");
- data.level = level + 1;
+ data.level = level + 2;
+ data.addr = NULL;
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_sp;
--
1.7.1
^ permalink raw reply related
* [PATCH] clk: divider: Use DIV_ROUND_CLOSEST
From: Soren Brinkmann @ 2013-01-30 1:25 UTC (permalink / raw)
To: linux-arm-kernel
Use the DIV_ROUND_CLOSEST macro to calculate divider values and minimize
rounding errors.
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
---
Hi,
I just came across this behavior:
I'm using the clk-divider as cpuclock which can be scaled through cpufreq.
During boot I create an opp table which in this case holds the frequencies [MHz]
666, 333 and 222. To make sure those are actually valid frequencies I call
clk_round_rate().
I added a debug line in clk-divider.c:clk_divider_bestdiv() before the return
in line 163 giving me:
prate:1333333320, rate:333333330, div:4
for adding the 333 MHz operating point.
In the running system this gives me:
zynq:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies
222222 333333 666666
zynq:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_cur_freq
666666
So far, so good. But now, let's scale the frequency:
zynq:/sys/devices/system/cpu/cpu0/cpufreq # echo 333333 > scaling_setspeed
zynq:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_cur_freq
266666
And the corresponding debug line:
prate:1333333320, rate:333333000, div:5
So, with DIV_ROUND_UP an actual divider of 4.00000396 becomes 5, resulting in a
huge error.
Regards,
S?ren
drivers/clk/clk-divider.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index a9204c6..32e1b6a 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -157,7 +157,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
if (!(__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT)) {
parent_rate = *best_parent_rate;
- bestdiv = DIV_ROUND_UP(parent_rate, rate);
+ bestdiv = DIV_ROUND_CLOSEST(parent_rate, rate);
bestdiv = bestdiv == 0 ? 1 : bestdiv;
bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
return bestdiv;
@@ -207,7 +207,7 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long flags = 0;
u32 val;
- div = parent_rate / rate;
+ div = DIV_ROUND_CLOSEST(parent_rate, rate);
value = _get_val(divider, div);
if (value > div_mask(divider))
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] ARM: kirkwood: provide ge clock aliases for shared smi
From: Sebastian Hesselbarth @ 2013-01-30 1:26 UTC (permalink / raw)
To: linux-arm-kernel
DT support for mv643xx_eth will split smi driver from core gbe driver.
Although different drivers, both use the same internal device and the
same (gateable) clock. This patch provides a proper clock alias for
the smi driver to not break non-DT kernels.
Reported-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Simon Baatz <gmbnomis@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
arch/arm/mach-kirkwood/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index bac21a5..502d80d 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -252,7 +252,9 @@ void __init kirkwood_clk_init(void)
orion_clkdev_add(NULL, "orion_spi.0", runit);
orion_clkdev_add(NULL, "orion_spi.1", runit);
orion_clkdev_add(NULL, MV643XX_ETH_NAME ".0", ge0);
+ orion_clkdev_add(NULL, MV643XX_ETH_SHARED_NAME ".0", ge0);
orion_clkdev_add(NULL, MV643XX_ETH_NAME ".1", ge1);
+ orion_clkdev_add(NULL, MV643XX_ETH_SHARED_NAME ".1", ge1);
orion_clkdev_add(NULL, "orion_wdt", tclk);
orion_clkdev_add("0", "sata_mv.0", sata0);
orion_clkdev_add("1", "sata_mv.0", sata1);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
From: Sebastian Hesselbarth @ 2013-01-30 1:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359509201-11674-1-git-send-email-sebastian.hesselbarth@gmail.com>
The ethernet controller used on kirkwood looses its MAC address
register contents when the corresponding clock is gated. Until there
is proper DT support for the mv643xx_eth driver, we add a workaround
to always enable ge0/ge1 clocks on kirkwood. This workaround is also
already used on non-DT kirkwood kernels.
Reported-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Simon Baatz <gmbnomis@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
arch/arm/mach-kirkwood/board-dt.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index de4fd2b..e714ead 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -41,16 +41,12 @@ static void __init kirkwood_legacy_clk_init(void)
struct device_node *np = of_find_compatible_node(
NULL, NULL, "marvell,kirkwood-gating-clock");
-
struct of_phandle_args clkspec;
+ struct clk *clk;
clkspec.np = np;
clkspec.args_count = 1;
- clkspec.args[0] = CGC_BIT_GE0;
- orion_clkdev_add(NULL, "mv643xx_eth_port.0",
- of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CGC_BIT_PEX0;
orion_clkdev_add("0", "pcie",
of_clk_get_from_provider(&clkspec));
@@ -63,14 +59,24 @@ static void __init kirkwood_legacy_clk_init(void)
orion_clkdev_add("1", "pcie",
of_clk_get_from_provider(&clkspec));
- clkspec.args[0] = CGC_BIT_GE1;
- orion_clkdev_add(NULL, "mv643xx_eth_port.1",
- of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CGC_BIT_SDIO;
orion_clkdev_add(NULL, "mvsdio",
of_clk_get_from_provider(&clkspec));
+ /*
+ * The ethernet interfaces forget the MAC address assigned by
+ * u-boot if the clocks are turned off. Until proper DT support
+ * is available we always enable them for now.
+ */
+ clkspec.args[0] = CGC_BIT_GE0;
+ clk = of_clk_get_from_provider(&clkspec);
+ orion_clkdev_add(NULL, "mv643xx_eth_port.0", clk);
+ clk_prepare_enable(clk);
+
+ clkspec.args[0] = CGC_BIT_GE1;
+ clk = of_clk_get_from_provider(&clkspec);
+ orion_clkdev_add(NULL, "mv643xx_eth_port.1", clk);
+ clk_prepare_enable(clk);
}
static void __init kirkwood_of_clk_init(void)
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox