* Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
From: Arnd Bergmann @ 2011-11-24 22:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Nicolas Pitre, linux-mips, linux-m68k, x86, linux-ia64,
Michael S. Tsirkin, linux-pci, linux, Jesse Barnes, Chen Liqin,
Paul Mackerras, Ralf Baechle, H. Peter Anvin, sparclinux,
Guan Xuetao, Lennox Wu, Jonas Bonn, Jesper Nilsson, Russell King,
linux-hexagon, Helge Deller, linux-sh, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Arend van Spriel, Matt Turner,
linux-arch, Lasse Collin, Lucas De Marchi, microblaze-uclinux,
Michal Simek, Rob Herring, Mikael Starvik, Ivan Kokshaysky,
Franky Lin, Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Paul Bolle, Tony Luck,
linux-cris-kernel, linux-parisc, Paul Gortmaker, linux-kernel,
Fenghua Yu, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Fabio Baltieri, David S. Miller
In-Reply-To: <b5a1327dd8bb38f87cba7ae10b308ec3b63de66a.1322163031.git.mst@redhat.com>
On Thursday 24 November 2011 22:17:02 Michael S. Tsirkin wrote:
> Many architectures want a generic pci_iomap but
> not the rest of iomap.c. Split that to a separate .c
> file and add a new config symbol. select automatically
> by GENERIC_IOMAP.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Very nice!
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [RFC PATCH v5 1/9] fadump: Add documentation for firmware-assisted dump.
From: Paul Mackerras @ 2011-11-24 22:34 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Amerigo Wang, Kexec-ml, Linux Kernel, Milton Miller, linuxppc-dev,
Randy Dunlap, Anton Blanchard, Vivek Goyal, Eric W. Biederman
In-Reply-To: <20111115151334.16533.5790.stgit@mars.in.ibm.com>
On Tue, Nov 15, 2011 at 08:43:34PM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> Documentation for firmware-assisted dump. This document is based on the
> original documentation written for phyp assisted dump by Linas Vepstas
> and Manish Ahuja, with few changes to reflect the current implementation.
>
> Change in v3:
> - Modified the documentation to reflect introdunction of fadump_registered
> sysfs file and few minor changes.
>
> Change in v2:
> - Modified the documentation to reflect the change of fadump_region
> file under debugfs filesystem.
In general we don't want the changes between successive versions in
the patch description; this information should go below the "---"
line. The patch description should describe how the patch is now and
give any information that will be useful to someone looking at the
resulting git commit later on, but it doesn't need to tell us about
previous versions of the patch that will never appear in the git
history.
> +-- Once the dump is copied out, the memory that held the dump
> + is immediately available to the running kernel. A further
> + reboot isn't required.
I have a general worry about the system making allocations that are
intended to be node-local while it is running with restricted memory
(i.e. after the crash and reboot and before the dump has been written
out and the dump memory freed). Those allocations will probably all
come from one node and thus won't necessarily be on the desired node.
So, for very large systems with significant NUMA characteristics, it
may be desirable (though not required) to reboot after taking the
dump.
What happens about the NUMA information in the kernel -- all the
memory sections, etc.? Do they get set up as normal even though the
second kernel is booting with only a small amount of memory initially?
> + /sys/kernel/debug/powerpc/fadump_region
> +
> + This file shows the reserved memory regions if fadump is
> + enabled otherwise this file is empty. The output format
> + is:
> + <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
> +
> + e.g.
> + Contents when fadump is registered during first kernel
> +
> + # cat /sys/kernel/debug/powerpc/fadump_region
> + CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
> + HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
> + DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
How come the HPTE region is only 0x1000 (4k) bytes? The hashed page
table (HPT) will be much bigger than this. Is this our way of telling
the hypervisor that we don't care about the HPT? If so, is it
possible to make this region 0 bytes instead of 0x1000?
Paul.
^ permalink raw reply
* Re: [RFC PATCH v5 2/9] fadump: Reserve the memory for firmware assisted dump.
From: Paul Mackerras @ 2011-11-24 23:02 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Anton Blanchard, Amerigo Wang, Kexec-ml, Linux Kernel,
Milton Miller, linuxppc-dev, Randy Dunlap, Eric W. Biederman,
Vivek Goyal
In-Reply-To: <20111115151343.16533.70101.stgit@mars.in.ibm.com>
On Tue, Nov 15, 2011 at 08:43:43PM +0530, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> Reserve the memory during early boot to preserve CPU state data, HPTE region
> and RMR region data in case of kernel crash. At the time of crash, powerpc
> firmware will store CPU state data, HPTE region data and move RMR region
> data to the reserved memory area.
What is "RMR"? I don't see anywhere that you explain this acronym.
Is it the same as the RMA (real mode area)?
> +config FA_DUMP
> + bool "Firmware-assisted dump"
Is this new fadump infrastructure intended to supersede the existing
phyp dump code? Does it use the same phyp interfaces as phyp dump?
If so, you should probably remove the phyp dump code and config option
as the final patch in your series.
> +/*
> + * The RMR region will be saved for later dumping when kernel crashes.
> + * Set this to RMO size.
> + */
> +#define RMR_START 0x0
> +#define RMR_END (ppc64_rma_size)
An explanation of "RMR" here, and what the distinction (if any)
between RMR and RMA/RMO is, would help future readers.
> + sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + &size);
> +
> + if (!sections)
> + return 0;
> +
> + num_sections = size / sizeof(struct dump_section);
> +
> + for (i = 0; i < num_sections; i++) {
> + switch (sections[i].dump_section) {
> + case FADUMP_CPU_STATE_DATA:
> + fw_dump.cpu_state_data_size = sections[i].section_size;
> + break;
> + case FADUMP_HPTE_REGION:
> + fw_dump.hpte_region_size = sections[i].section_size;
> + break;
It's generally better to use of_read_number() or of_read_ulong() to
parse OF properties, rather than using a structure like this.
> + /* divide by 20 to get 5% of value */
> + size = memblock_end_of_DRAM();
> + do_div(size, 20);
You could just say size = memblock_end_of_DRAM() / 20 here; no need to
use do_div, since we won't be using this code on 32-bit platforms.
> + if (!fw_dump.fadump_supported) {
> + printk(KERN_ERR "Firmware-assisted dump is not supported on"
> + " this hardware\n");
This shouldn't be KERN_ERR; it's not an error to boot a kernel with
fadump configured in on a machine that doesn't have firmware fadump
support. I don't think we really need any message, but if we have one
it should be KERN_INFO at most.
> +/* Look for fadump= cmdline option. */
> +static int __init early_fadump_param(char *p)
> +{
> + if (!p)
> + return 1;
> +
> + if (p[0] == '1')
> + fw_dump.fadump_enabled = 1;
> + else if (p[0] == '0')
> + fw_dump.fadump_enabled = 0;
I think it's usual to allow "on" and "off" as values for this kind of
option. There might be a handy little helper function to parse this
sort of thing (but if there is I don't know what it is called).
Paul.
^ permalink raw reply
* Re: [PATCH 03/13] powerpc: Fix booke hugetlb preload code for PPC_MM_SLICES and 64-bit
From: Benjamin Herrenschmidt @ 2011-11-25 0:43 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, david
In-Reply-To: <13182798681100-git-send-email-beckyb@kernel.crashing.org>
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
.../...
> #ifdef CONFIG_PPC_MM_SLICES
> - psize = mmu_get_tsize(get_slice_psize(mm, ea));
> - tsize = mmu_get_psize(psize);
> + psize = get_slice_psize(mm, ea);
> + tsize = mmu_get_tsize(psize);
> shift = mmu_psize_defs[psize].shift;
> #else
> - vma = find_vma(mm, ea);
> - psize = vma_mmu_pagesize(vma); /* returns actual size in bytes */
> - asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (psize));
> - shift = 31 - lz;
> - tsize = 21 - lz;
> + psize = vma_mmu_pagesize(find_vma(mm, ea));
> + shift = __ilog2(psize);
> + tsize = shift - 10;
> #endif
Now, I know it was already there and you are just moving it around in
this patch but come on ... find_vma() here ? Really ? And with no result
checking nor boundary checking (remember it can return a vma that
doesn't enclose the address etc....). Now I know in this specific case
it -should- be safe but still...
Now, the caller is just doing:
book3e_hugetlb_preload(vma->vm_mm, address, *ptep);
So why not just change the prototype and pass the vma down instead ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
From: Stephen Rothwell @ 2011-11-25 0:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64, linux-sh,
linux-pci, linux, Jesse Barnes, Chen Liqin, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Guan Xuetao, Lennox Wu,
Jonas Bonn, Jesper Nilsson, Russell King, linux-hexagon,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Arend van Spriel, Matt Turner, linux-arch,
Lasse Collin, Arnd Bergmann, Lucas De Marchi, microblaze-uclinux,
Michal Simek, Rob Herring, Mikael Starvik, Ivan Kokshaysky,
Franky Lin, Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Paul Bolle, Tony Luck,
linux-cris-kernel, linux-parisc, Paul Gortmaker, linux-kernel,
Fenghua Yu, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Fabio Baltieri, linuxppc-dev, David S. Miller
In-Reply-To: <b5a1327dd8bb38f87cba7ae10b308ec3b63de66a.1322163031.git.mst@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5328 bytes --]
Hi Michael,
On Thu, 24 Nov 2011 22:17:02 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 9120887..c8a67345 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -19,6 +19,8 @@
> #include <asm-generic/iomap.h>
> #endif
>
> +#include <asm-generic/pci_iomap.h>
> +
> #ifndef mmiowb
> #define mmiowb() do {} while (0)
> #endif
> @@ -283,9 +285,6 @@ static inline void writesb(const void __iomem *addr, const void *buf, int len)
> #define __io_virt(x) ((void __force *) (x))
>
> #ifndef CONFIG_GENERIC_IOMAP
> -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> -struct pci_dev;
> -extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
> {
> }
Just wondering why you move pci_iomap but not pic_iounmap. And also if
pci_iounmap is meant to stay here, then the "struct pci_dev" should
probably stay as well.
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index 98dcd76..fdcddcb 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -69,16 +69,13 @@ extern void ioport_unmap(void __iomem *);
> #ifdef CONFIG_PCI
> /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> struct pci_dev;
> -extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
Ditto with pci_iounmap. Also the comment above really belongs with pci_iomap.
> diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
> new file mode 100644
> index 0000000..e08b3bd
> --- /dev/null
> +++ b/include/asm-generic/pci_iomap.h
> @@ -0,0 +1,26 @@
> +/* Generic I/O port emulation, based on MN10300 code
> + *
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +#ifndef __ASM_GENERIC_PCI_IOMAP_H
> +#define __ASM_GENERIC_PCI_IOMAP_H
> +
> +#ifdef CONFIG_PCI
> +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> +struct pci_dev;
You could move this struct declaration above the ifdef and remove the
duplicate below.
> +extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> +#else
> +struct pci_dev;
> +static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
> +{
> + return NULL;
> +}
> +#endif
> +
> +#endif /* __ASM_GENERIC_IO_H */
> diff --git a/lib/iomap.c b/lib/iomap.c
> index 5dbcb4b..ada922a 100644
> --- a/lib/iomap.c
> +++ b/lib/iomap.c
> @@ -242,45 +242,11 @@ EXPORT_SYMBOL(ioport_unmap);
> #endif /* CONFIG_HAS_IOPORT */
>
> #ifdef CONFIG_PCI
> -/**
> - * pci_iomap - create a virtual mapping cookie for a PCI BAR
> - * @dev: PCI device that owns the BAR
> - * @bar: BAR number
> - * @maxlen: length of the memory to map
> - *
> - * Using this function you will get a __iomem address to your device BAR.
> - * You can access it using ioread*() and iowrite*(). These functions hide
> - * the details if this is a MMIO or PIO address space and will just do what
> - * you expect from them in the correct way.
> - *
> - * @maxlen specifies the maximum length to map. If you want to get access to
> - * the complete BAR without checking for its length first, pass %0 here.
> - * */
> -void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> -{
> - resource_size_t start = pci_resource_start(dev, bar);
> - resource_size_t len = pci_resource_len(dev, bar);
> - unsigned long flags = pci_resource_flags(dev, bar);
> -
> - if (!len || !start)
> - return NULL;
> - if (maxlen && len > maxlen)
> - len = maxlen;
> - if (flags & IORESOURCE_IO)
> - return ioport_map(start, len);
> - if (flags & IORESOURCE_MEM) {
> - if (flags & IORESOURCE_CACHEABLE)
> - return ioremap(start, len);
> - return ioremap_nocache(start, len);
> - }
> - /* What? */
> - return NULL;
> -}
> -
> +/* Hide the details if this is a MMIO or PIO address space and just do what
> + * you expect in the correct way. */
> void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
> {
> IO_COND(addr, /* nothing */, iounmap(addr));
> }
> -EXPORT_SYMBOL(pci_iomap);
> EXPORT_SYMBOL(pci_iounmap);
Ditto with pci_iounmap
> diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
> new file mode 100644
> index 0000000..40b26cb
> --- /dev/null
> +++ b/lib/pci_iomap.c
> @@ -0,0 +1,48 @@
> +/*
> + * Implement the default iomap interfaces
> + *
> + * (C) Copyright 2004 Linus Torvalds
> + */
> +#include <linux/pci.h>
> +#include <linux/io.h>
> +
> +#include <linux/module.h>
If this is relative to (at least) v3.2-rc1, then you should use export.h
instead of module.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
From: Stephen Rothwell @ 2011-11-25 0:59 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips, linux-m68k, linux-ia64, linux-sh,
linux-pci, linux, Jesse Barnes, Chen Liqin, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Guan Xuetao, Lennox Wu,
Jonas Bonn, Jesper Nilsson, Russell King, linux-hexagon,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Arend van Spriel, Matt Turner, linux-arch,
Lasse Collin, Arnd Bergmann, Lucas De Marchi, microblaze-uclinux,
Michal Simek, Rob Herring, Mikael Starvik, Ivan Kokshaysky,
Franky Lin, Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Richard Henderson, Michael Ellerman, Paul Bolle, Tony Luck,
linux-cris-kernel, linux-parisc, Paul Gortmaker, linux-kernel,
Fenghua Yu, Richard Kuo, Kyle McMartin, Paul Mundt, linux-alpha,
Olof Johansson, Fabio Baltieri, linuxppc-dev, David S. Miller
In-Reply-To: <20111125115455.9d5e18da6e683586d84ed9c8@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
Hi Michael,
On Fri, 25 Nov 2011 11:54:55 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Just wondering why you move pci_iomap but not pic_iounmap.
I figured this out. Arches have their own.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-11-25 3:15 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-m68k, linuxppc-dev, linux-serial, Geert Uytterhoeven
In-Reply-To: <20111124145624.24438832@lxorguk.ukuu.org.uk>
On Thu, 24 Nov 2011, Alan Cox wrote:
> Given the change should work for all hardware do we really need the
> ifdefs. Far better I would have thought to just change it so we don't
> have to maintain what is effectively two versions of the code between
> now and 2038.
I agree.
>
> So no ack from me yet - I'd like to understand the ifdef decision first.
Removing ifdefs makes the changes more invasive and the suspend/resume
code then has to be addressed, which I've avoided.
The suspend/resume code path can't be tested on m68k macs and the common
code paths I can't easily test on a powermac.
This patch should not be needed because the chip reset shouldn't leave the
tx and rx interrupts enabled. Those interrupts are explicitly enabled only
after request_irq(), so patching the master interrupt enable behaviour
should be redundant. But that's not the case in practice.
The chip reset code is already messy. I was inclined towards ifdefs and
reluctant to share more code after practical experience suggested possible
differences in the SCC/ESCC devices.
I guess I was hoping that the powermac maintainers might prefer ifdefs to
increased risk of destabilising the driver on powermacs...
But a more invasive patch would make for better code. I will see if I can
borrow a suitable PCI PowerMac.
Finn
> Otherwise it looks sensible.
>
> Alan
^ permalink raw reply
* Re: [PATCH 5/5] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Benjamin Herrenschmidt @ 2011-11-25 3:41 UTC (permalink / raw)
To: Matthew McClintock; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1319583246-6120-5-git-send-email-msm@freescale.com>
On Tue, 2011-10-25 at 17:54 -0500, Matthew McClintock wrote:
> boot_cpuid and init_thread_info.cpu are redundant, just use the
> var that stays around longer and add a define to make boot_cpuid
> point at the correct value
Breaks pseries build. Looks trivial but I haven't had a chance to fix
it (obvious one liner didn't do it and no time today).
Please re-submit fixed.
Cheers,
Ben.
> boot_cpudid_phys is not needed and can completely go away from the
> SMP case, we leave it there for the non-SMP case since the paca
> struct is not around to store this info
>
> This patch also has the effect of having the logical cpu number
> of the boot cpu be updated correctly independently of the ordering
> of the cpu nodes in the device tree.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> Could also just change boot_cpuid every to init_thread_info.cpu instead
> of using this define
>
> This is only tested on 32-bit parts, only compiled on 64-bit
>
> arch/powerpc/include/asm/smp.h | 2 +-
> arch/powerpc/kernel/setup_32.c | 7 ++++---
> arch/powerpc/kernel/setup_64.c | 1 -
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index adba970..f26c554 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -29,7 +29,7 @@
> #endif
> #include <asm/percpu.h>
>
> -extern int boot_cpuid;
> +#define boot_cpuid (init_thread_info.cpu)
> extern int spinning_secondaries;
>
> extern void cpu_die(void);
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index c1ce863..f396847 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -46,10 +46,11 @@
>
> extern void bootx_init(unsigned long r4, unsigned long phys);
>
> -int boot_cpuid = -1;
> -EXPORT_SYMBOL_GPL(boot_cpuid);
> -int boot_cpuid_phys;
> +/* we need a place to store phys cpu for non-SMP case */
> +#ifndef CONFIG_SMP
> +int boot_cpuid_phys = -1;
> EXPORT_SYMBOL_GPL(boot_cpuid_phys);
> +#endif
>
> int smp_hw_index[NR_CPUS];
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index d4168c9..eacefba 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -73,7 +73,6 @@
> #define DBG(fmt...)
> #endif
>
> -int boot_cpuid = 0;
> int __initdata spinning_secondaries;
> u64 ppc64_pft_size;
>
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-11-25 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a handful of tiny fixes for ppc, essentially embedded bits and
all reasonably trivial.
Cheers,
Ben.
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Alexandre Rusev (1):
powerpc/fsl-lbc: Fix for fsl_upm
Joakim Tjernlund (1):
powerpc/qe: Fixup QE_General4 errata
Julia Lawall (1):
arch/powerpc/sysdev/ehv_pic.c: add missing kfree
Kumar Gala (2):
powerpc/85xx: Fix compile error on p3060_qds.c
powerpc: Fix compiliation with hugetlbfs enabled
Paul Bolle (1):
powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
Roy Zang (1):
powerpc/p1023: set IRQ[4:6,11] to active-high level sensitive for PCIe
Shaohui Xie (1):
drivers/edac/mpc85xx_edac.c: fix memory controller compatible for edac
Tony Breeds (1):
powerpc/44x: Add mtd ndfc to the ppx44x defconfig
arch/powerpc/boot/dts/p1023rds.dts | 17 +++++++++++++----
arch/powerpc/configs/ppc44x_defconfig | 2 ++
arch/powerpc/mm/hugetlbpage.c | 1 +
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
arch/powerpc/sysdev/ehv_pic.c | 1 +
arch/powerpc/sysdev/fsl_lbc.c | 1 +
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
drivers/edac/mpc85xx_edac.c | 2 +-
9 files changed, 22 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Benjamin Herrenschmidt @ 2011-11-25 5:24 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Robert Richter, linuxppc-dev, Andy Fleming, oprofile-list
In-Reply-To: <OFD2223A5C.914A7555-ONC125794C.002D68B7-C125794C.002DFF90@transmode.se>
On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
> I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
> correct backtrace but I cannot turn on frame pointers for the ppc kernel.
> Isn't frame pointers needed for pcc? what about user space?
PowerPC always has frame pointers, ignore that :-)
Cheers,
Ben.
^ permalink raw reply
* Re: ibm_newemac tx problem with jumbo frame enabled
From: Benjamin Herrenschmidt @ 2011-11-25 5:25 UTC (permalink / raw)
To: Prashant Bhole; +Cc: linuxppc-dev
In-Reply-To: <CAD6p20dmksH7YEjijdqLRG06aigaKTpzLPdoL0SCNGD3Ji9d2A@mail.gmail.com>
On Fri, 2011-11-18 at 10:33 +0530, Prashant Bhole wrote:
> Hi,
> I have been facing problem with ibm_newemac driver (v3.54).
> The board gets disconnected and can not be pinged in between
> some heavy network traffic. In my case I am running IOmeter
> "All-in-One" 8 threads on the iSCSI target. MTU is 4088.
>
> I found that after executing emac_full_tx_reset(), the board can
> be pinged again. Again after some heavy traffic of 5-6 seconds,
> traffic stops. This can be repeated after full tx reset.
>
> Is this a known issue? what could cause this?
> Any pointers would be greatly appreciated.
Not that I know of. Can you check if any of the error reporting
registers trip anything ? Could it just be a fifo overflow which we may
not be handling properly in the driver ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Decode correct MSR bits in oops output
From: Anton Blanchard @ 2011-11-25 5:35 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
On a 64bit book3s machine I have an oops from a system reset that
claims the book3e CE bit was set:
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 24004082 XER: 00000010
On a book3s machine system reset sets IBM bit 46 and 47 depending on
the power saving mode. Separate the definitions by type and for
completeness add the rest of the bits in.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/process.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/process.c 2011-11-25 13:22:24.294919094 +1100
+++ linux-build/arch/powerpc/kernel/process.c 2011-11-25 13:36:23.213834524 +1100
@@ -584,16 +584,32 @@ static struct regbit {
unsigned long bit;
const char *name;
} msr_bits[] = {
+#if defined(CONFIG_PPC64) && !defined(CONFIG_BOOKE)
+ {MSR_SF, "SF"},
+ {MSR_HV, "HV"},
+#endif
+ {MSR_VEC, "VEC"},
+ {MSR_VSX, "VSX"},
+#ifdef CONFIG_BOOKE
+ {MSR_CE, "CE"},
+#endif
{MSR_EE, "EE"},
{MSR_PR, "PR"},
{MSR_FP, "FP"},
- {MSR_VEC, "VEC"},
- {MSR_VSX, "VSX"},
{MSR_ME, "ME"},
- {MSR_CE, "CE"},
+#ifdef CONFIG_BOOKE
{MSR_DE, "DE"},
+#else
+ {MSR_SE, "SE"},
+ {MSR_BE, "BE"},
+#endif
{MSR_IR, "IR"},
{MSR_DR, "DR"},
+ {MSR_PMM, "PMM"},
+#ifndef CONFIG_BOOKE
+ {MSR_RI, "RI"},
+ {MSR_LE, "LE"},
+#endif
{0, NULL}
};
^ permalink raw reply
* [PATCH] powerpc: Harden xics hypervisor backend
From: Anton Blanchard @ 2011-11-25 5:39 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
During kdump stress testing I sometimes see the kdump kernel panic
with:
Interrupt 0x306 (real) is invalid, disabling it.
Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306
Instead of panicing print the error message, dump the stack the first
time it happens and continue on. Add some more information to the
debug messages as well.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/sysdev/xics/icp-hv.c
===================================================================
--- linux-build.orig/arch/powerpc/sysdev/xics/icp-hv.c 2011-11-25 14:01:50.756984686 +1100
+++ linux-build/arch/powerpc/sysdev/xics/icp-hv.c 2011-11-25 14:13:22.389244117 +1100
@@ -27,33 +27,49 @@ static inline unsigned int icp_hv_get_xi
{
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
long rc;
+ unsigned int ret = XICS_IRQ_SPURIOUS;
rc = plpar_hcall(H_XIRR, retbuf, cppr);
- if (rc != H_SUCCESS)
- panic(" bad return code xirr - rc = %lx\n", rc);
- return (unsigned int)retbuf[0];
+ if (rc == H_SUCCESS) {
+ ret = (unsigned int)retbuf[0];
+ } else {
+ pr_err("%s: bad return code xirr cppr=0x%x returned %ld\n",
+ __func__, cppr, rc);
+ WARN_ON_ONCE(1);
+ }
+
+ return ret;
}
static inline void icp_hv_set_xirr(unsigned int value)
{
long rc = plpar_hcall_norets(H_EOI, value);
- if (rc != H_SUCCESS)
- panic("bad return code EOI - rc = %ld, value=%x\n", rc, value);
+ if (rc != H_SUCCESS) {
+ pr_err("%s: bad return code eoi xirr=0x%x returned %ld\n",
+ __func__, value, rc);
+ WARN_ON_ONCE(1);
+ }
}
static inline void icp_hv_set_cppr(u8 value)
{
long rc = plpar_hcall_norets(H_CPPR, value);
- if (rc != H_SUCCESS)
- panic("bad return code cppr - rc = %lx\n", rc);
+ if (rc != H_SUCCESS) {
+ pr_err("%s: bad return code cppr cppr=0x%x returned %ld\n",
+ __func__, value, rc);
+ WARN_ON_ONCE(1);
+ }
}
static inline void icp_hv_set_qirr(int n_cpu , u8 value)
{
- long rc = plpar_hcall_norets(H_IPI, get_hard_smp_processor_id(n_cpu),
- value);
- if (rc != H_SUCCESS)
- panic("bad return code qirr - rc = %lx\n", rc);
+ int hw_cpu = get_hard_smp_processor_id(n_cpu);
+ long rc = plpar_hcall_norets(H_IPI, hw_cpu, value);
+ if (rc != H_SUCCESS) {
+ pr_err("%s: bad return code qirr cpu=%d hw_cpu=%d mfrr=0x%x "
+ "returned %ld\n", __func__, n_cpu, hw_cpu, value, rc);
+ WARN_ON_ONCE(1);
+ }
}
static void icp_hv_eoi(struct irq_data *d)
^ permalink raw reply
* [PATCH] powerpc: Atomically output each stack frame line in show_stack
From: Anton Blanchard @ 2011-11-25 5:47 UTC (permalink / raw)
To: benh, paulus, miltonm; +Cc: linuxppc-dev
From: Milton Miller <miltonm@bga.com>
show_stack uses up to 4 printks per line and other CPUs using printk
can corrupt the output. This patch calls printk once per stack frame
line to produce more readable output.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/process.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/process.c 2011-11-25
16:44:06.548045629 +1100 +++
linux-build/arch/powerpc/kernel/process.c 2011-11-25
16:44:07.944070260 +1100 @@ -1147,7 +1147,7 @@ void show_stack(struct
task_struct *tsk, { unsigned long sp, ip, lr, newsp;
int count = 0;
- int firstframe = 1;
+ char *firstframe = " (unreliable)";
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
int curr_frame = current->curr_ret_stack;
extern void return_to_handler(void);
@@ -1180,20 +1180,20 @@ void show_stack(struct task_struct *tsk,
stack = (unsigned long *) sp;
newsp = stack[0];
ip = stack[STACK_FRAME_LR_SAVE];
- if (!firstframe || ip != lr) {
- printk("["REG"] ["REG"] %pS", sp, ip, (void
*)ip);
+ if (!firstframe[0] || ip != lr) {
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
if ((ip == rth || ip == mrth) && curr_frame >=
0) {
- printk(" (%pS)",
- (void
*)current->ret_stack[curr_frame].ret);
+ printk("["REG"] ["REG"] %pS
(%pS)%s\n", sp, ip,
+ (void *)ip, (void *)
+
current->ret_stack[curr_frame].ret,
+ firstframe);
curr_frame--;
- }
+ } else
#endif
- if (firstframe)
- printk(" (unreliable)");
- printk("\n");
+ printk("["REG"] ["REG"] %pS%s\n", sp,
ip,
+ (void *)ip, firstframe);
}
- firstframe = 0;
+ firstframe = "";
/*
* See if this is an exception frame.
@@ -1206,7 +1206,7 @@ void show_stack(struct task_struct *tsk,
lr = regs->link;
printk("--- Exception: %lx at %pS\n LR =
%pS\n", regs->trap, (void *)regs->nip, (void *)lr);
- firstframe = 1;
+ firstframe = " (unreliable)";
}
sp = newsp;
^ permalink raw reply
* Re: oprofile callgraph support missing for common cpus
From: Juntang Fu(David) @ 2011-11-25 5:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, oprofile-list, Fleming, Andy
In-Reply-To: <1322198672.32635.24.camel@pasglop>
On 11/25/2011 01:24 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote:
>
>> I forgot to ask, oprofile mentions setting -no-omit-framepointer to get
>> correct backtrace but I cannot turn on frame pointers for the ppc kernel.
>> Isn't frame pointers needed for pcc? what about user space?
> PowerPC always has frame pointers, ignore that :-)
Recently I have met a similar problem on frame pointer but at arm_v7
variant in back tracing
support for Oprofile, could you help me see it? thanks in advance:
in my case, I have enabled Oprofile support in my arm_v7 thumb2 target,
in the created binary image
including kernel image and rootfs, seems that frame pointer is not
enabled for arm thumb2, So I have met
the following problems in back trace:
I can get the right stack traces for kernel stack, but for user stack, the
stack length is always one depth, why?
Is this a known deficiency in supporting arm thumb2 for Oprofile stack
trace?
Thanks.
B.R.
--David
> Cheers,
> Ben.
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
^ permalink raw reply
* RE: Enabling MBX in MPC5121 - OGLES kernel modules
From: Einar Már Björgvinsson @ 2011-11-25 8:20 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <76E1146DEE728E4E95C1C6D1EEA1DBA96F174768@GRBSR0004.marel.net>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Hi
Wanted to repeat my previous email about enabling MBX in MPC5121.
Anybody out there who can assist me ?
regards
Einar
________________________________
From: Einar Már Björgvinsson
Sent: Tuesday, November 22, 2011 7:15 PM
To: linuxppc-dev@lists.ozlabs.org
Subject: Enabling MBX in MPC5121 - OGLES kernel modules
Hi
I've been working on enabling the PowerVR GPU core in MPC5121 chip. I've been following the documentation from here:
http://www.datasheetarchive.com/indexdl/Datasheet-076/DSAE0026055.pdf
This documentation was released in a bundle with MBX libraries and MBX kernel patches. Also have I downloaded the OGLES SDK from Imgtech where I've successfully built some demos for MPC5121.
The last piece of the puzzle is to have the right kernel modules. There are some kernel modules provided in the documentation bundle but they are build against older kernel version (2.6.24) but I'm am using kernel version 2.6.33 with RT 29.
What I'm hoping is that somebody have the source code for the following kernel modules:
- pvr.ko
- clcdc.ko
- swcamera.ko
- dgbdrv.ko
Hope somebody out there can assist
Regards
Einar M. Bjorgvinsson
Embedded Software Engineer
Marel ehf
Iceland
[-- Attachment #2: Type: text/html, Size: 2269 bytes --]
^ permalink raw reply
* Re: [PATCH-RFC 01/10] lib: move GENERIC_IOMAP to lib/Kconfig
From: Jesper Nilsson @ 2011-11-25 8:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Nicolas Pitre, linux-mips@linux-mips.org,
linux-m68k@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-sh@vger.kernel.org, linux@openrisc.net,
linux-pci@vger.kernel.org, Jesse Barnes, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux@vger.kernel.org,
Guan Xuetao, Lennox Wu, Jonas Bonn, Russell King,
linux-hexagon@vger.kernel.org, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
linux-arch@vger.kernel.org, Arend van Spriel, Matt Turner,
Fenghua Yu, Lasse Collin, Arnd Bergmann, Lucas De Marchi,
microblaze-uclinux@itee.uq.edu.au, Paul Bolle, Rob Herring,
Mikael Starvik, Ivan Kokshaysky, Franky Lin, Thomas Gleixner,
Fabio Baltieri, linux-arm-kernel@lists.infradead.org,
Richard Henderson, Michael Ellerman, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel, Paul Gortmaker,
linux-kernel@vger.kernel.org, Ralf Baechle, Richard Kuo,
Kyle McMartin, Paul Mundt, linux-alpha@vger.kernel.org,
Olof Johansson, Andrew Morton, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <5aed7b7e1dbc8a50ebd6986245df8054fd05b7cd.1322163031.git.mst@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
On Thu, Nov 24, 2011 at 09:15:42PM +0100, Michael S. Tsirkin wrote:
> define GENERIC_IOMAP in a central location
> instead of all architectures. This will be helpful
> for the follow-up patch which makes it select
> other configs. Code is also a bit shorter this way.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
For the CRIS part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH net-next v2 3/4] can: cc770: add platform bus driver for the CC770 and AN82527
From: Wolfgang Grandegger @ 2011-11-25 9:43 UTC (permalink / raw)
To: netdev
Cc: Stanislav Yelenskiy, Devicetree-discuss, linux-can, linuxppc-dev,
IreneV, socketcan-users
In-Reply-To: <1322214204-1121-1-git-send-email-wg@grandegger.com>
This driver works with both, static platform data and device tree
bindings. It has been tested on a TQM855L board with two AN82527
CAN controllers on the local bus.
CC: Devicetree-discuss@lists.ozlabs.org
CC: linuxppc-dev@ozlabs.org
CC: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
.../devicetree/bindings/net/can/cc770.txt | 56 ++++
drivers/net/can/cc770/Kconfig | 7 +
drivers/net/can/cc770/Makefile | 1 +
drivers/net/can/cc770/cc770_platform.c | 289 ++++++++++++++++++++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/cc770.txt
create mode 100644 drivers/net/can/cc770/cc770_platform.c
diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt
new file mode 100644
index 0000000..01e282d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/cc770.txt
@@ -0,0 +1,56 @@
+Memory mapped Bosch CC770 and Intel AN82527 CAN controller
+
+Note: The CC770 is a CAN controller from Bosch, which is 100%
+compatible with the old AN82527 from Intel, but with "bugs" being fixed.
+
+Required properties:
+
+- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
+ for the AN82527.
+
+- reg : should specify the chip select, address offset and size required
+ to map the registers of the controller. The size is usually 0x80.
+
+- interrupts : property with a value describing the interrupt source
+ (number and sensitivity) required for the controller.
+
+Optional properties:
+
+- bosch,external-clock-frequency : frequency of the external oscillator
+ clock in Hz. Note that the internal clock frequency used by the
+ controller is half of that value. If not specified, a default
+ value of 16000000 (16 MHz) is used.
+
+- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
+ If not specified or if the specified value is 0, the CLKOUT pin
+ will be disabled.
+
+- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
+ a resonable value will be calculated.
+
+- bosch,disconnect-rx0-input : see data sheet.
+
+- bosch,disconnect-rx1-input : see data sheet.
+
+- bosch,disconnect-tx1-output : see data sheet.
+
+- bosch,polarity-dominant : see data sheet.
+
+- bosch,divide-memory-clock : see data sheet.
+
+- bosch,iso-low-speed-mux : see data sheet.
+
+For further information, please have a look to the CC770 or AN82527.
+
+Examples:
+
+can@3,100 {
+ compatible = "bosch,cc770";
+ reg = <3 0x100 0x80>;
+ interrupts = <2 0>;
+ interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+};
+
+
+
diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
index 28e4d48..22c07a8 100644
--- a/drivers/net/can/cc770/Kconfig
+++ b/drivers/net/can/cc770/Kconfig
@@ -11,4 +11,11 @@ config CAN_CC770_ISA
connected to the ISA bus using I/O port, memory mapped or
indirect access.
+config CAN_CC770_PLATFORM
+ tristate "Generic Platform Bus based CC770 driver"
+ ---help---
+ This driver adds support for the CC770 and AN82527 chips
+ connected to the "platform bus" (Linux abstraction for directly
+ to the processor attached devices).
+
endif
diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
index 872ecff..9fb8321 100644
--- a/drivers/net/can/cc770/Makefile
+++ b/drivers/net/can/cc770/Makefile
@@ -4,5 +4,6 @@
obj-$(CONFIG_CAN_CC770) += cc770.o
obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
+obj-$(CONFIG_CAN_CC770_PLATFORM) += cc770_platform.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/cc770/cc770_platform.c b/drivers/net/can/cc770/cc770_platform.c
new file mode 100644
index 0000000..a33f91d
--- /dev/null
+++ b/drivers/net/can/cc770/cc770_platform.c
@@ -0,0 +1,289 @@
+/*
+ * Driver for CC770 and AN82527 CAN controllers on the platform bus
+ *
+ * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * 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.
+ */
+
+/*
+ * If platform data are used you should have similar definitions
+ * in your board-specific code:
+ *
+ * static struct cc770_platform_data myboard_cc770_pdata = {
+ * .osc_freq = 16000000,
+ * .cir = 0x41,
+ * .cor = 0x20,
+ * .bcr = 0x40,
+ * };
+ *
+ * Please see include/linux/can/platform/cc770.h for description of
+ * above fields.
+ *
+ * If the device tree is used, you need a CAN node definition in your
+ * DTS file similar to:
+ *
+ * can@3,100 {
+ * compatible = "bosch,cc770";
+ * reg = <3 0x100 0x80>;
+ * interrupts = <2 0>;
+ * interrupt-parent = <&mpic>;
+ * bosch,external-clock-frequency = <16000000>;
+ * };
+ *
+ * See "Documentation/devicetree/bindings/net/can/cc770.txt" for further
+ * information.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/delay.h>
+#include <linux/can.h>
+#include <linux/can/dev.h>
+#include <linux/can/platform/cc770.h>
+
+#include <linux/of_platform.h>
+
+#include "cc770.h"
+
+#define DRV_NAME "cc770_platform"
+
+MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
+MODULE_DESCRIPTION("Socket-CAN driver for CC770 on the platform bus");
+MODULE_LICENSE("GPL v2");
+
+#define CC770_PLATFORM_CAN_CLOCK 16000000
+
+static u8 cc770_platform_read_reg(const struct cc770_priv *priv, int reg)
+{
+ return in_8(priv->reg_base + reg);
+}
+
+static void cc770_platform_write_reg(const struct cc770_priv *priv, int reg,
+ u8 val)
+{
+ out_8(priv->reg_base + reg, val);
+}
+
+static int __devinit cc770_get_of_node_data(struct platform_device *pdev,
+ struct cc770_priv *priv)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const u32 *prop;
+ int prop_size;
+ u32 clkext;
+
+ prop = of_get_property(np, "bosch,external-clock-frequency",
+ &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ clkext = *prop;
+ else
+ clkext = CC770_PLATFORM_CAN_CLOCK; /* default */
+ priv->can.clock.freq = clkext;
+
+ /* The system clock may not exceed 10 MHz */
+ if (priv->can.clock.freq > 10000000) {
+ priv->cpu_interface |= CPUIF_DSC;
+ priv->can.clock.freq /= 2;
+ }
+
+ /* The memory clock may not exceed 8 MHz */
+ if (priv->can.clock.freq > 8000000)
+ priv->cpu_interface |= CPUIF_DMC;
+
+ if (of_get_property(np, "bosch,divide-memory-clock", NULL))
+ priv->cpu_interface |= CPUIF_DMC;
+ if (of_get_property(np, "bosch,iso-low-speed-mux", NULL))
+ priv->cpu_interface |= CPUIF_MUX;
+
+ if (!of_get_property(np, "bosch,no-comperator-bypass", NULL))
+ priv->bus_config |= BUSCFG_CBY;
+ if (of_get_property(np, "bosch,disconnect-rx0-input", NULL))
+ priv->bus_config |= BUSCFG_DR0;
+ if (of_get_property(np, "bosch,disconnect-rx1-input", NULL))
+ priv->bus_config |= BUSCFG_DR1;
+ if (of_get_property(np, "bosch,disconnect-tx1-output", NULL))
+ priv->bus_config |= BUSCFG_DT1;
+ if (of_get_property(np, "bosch,polarity-dominant", NULL))
+ priv->bus_config |= BUSCFG_POL;
+
+ prop = of_get_property(np, "bosch,clock-out-frequency", &prop_size);
+ if (prop && (prop_size == sizeof(u32)) && *prop > 0) {
+ u32 cdv = clkext / *prop;
+ int slew;
+
+ if (cdv > 0 && cdv < 16) {
+ priv->cpu_interface |= CPUIF_CEN;
+ priv->clkout |= (cdv - 1) & CLKOUT_CD_MASK;
+
+ prop = of_get_property(np, "bosch,slew-rate",
+ &prop_size);
+ if (prop && (prop_size == sizeof(u32))) {
+ slew = *prop;
+ } else {
+ /* Determine default slew rate */
+ slew = (CLKOUT_SL_MASK >>
+ CLKOUT_SL_SHIFT) -
+ ((cdv * clkext - 1) / 8000000);
+ if (slew < 0)
+ slew = 0;
+ }
+ priv->clkout |= (slew << CLKOUT_SL_SHIFT) &
+ CLKOUT_SL_MASK;
+ } else {
+ dev_dbg(&pdev->dev, "invalid clock-out-frequency\n");
+ }
+ }
+
+ return 0;
+}
+
+static int __devinit cc770_get_platform_data(struct platform_device *pdev,
+ struct cc770_priv *priv)
+{
+
+ struct cc770_platform_data *pdata = pdev->dev.platform_data;
+
+ priv->can.clock.freq = pdata->osc_freq;
+ if (priv->cpu_interface | CPUIF_DSC)
+ priv->can.clock.freq /= 2;
+ priv->clkout = pdata->cor;
+ priv->bus_config = pdata->bcr;
+ priv->cpu_interface = pdata->cir;
+
+ return 0;
+}
+
+static int __devinit cc770_platform_probe(struct platform_device *pdev)
+{
+ struct net_device *dev;
+ struct cc770_priv *priv;
+ struct resource *mem;
+ resource_size_t mem_size;
+ void __iomem *base;
+ int err, irq;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ irq = platform_get_irq(pdev, 0);
+ if (!mem || irq <= 0)
+ return -ENODEV;
+
+ mem_size = resource_size(mem);
+ if (!request_mem_region(mem->start, mem_size, pdev->name))
+ return -EBUSY;
+
+ base = ioremap(mem->start, mem_size);
+ if (!base) {
+ err = -ENOMEM;
+ goto exit_release_mem;
+ }
+
+ dev = alloc_cc770dev(0);
+ if (!dev) {
+ err = -ENOMEM;
+ goto exit_unmap_mem;
+ }
+
+ dev->irq = irq;
+ priv = netdev_priv(dev);
+ priv->read_reg = cc770_platform_read_reg;
+ priv->write_reg = cc770_platform_write_reg;
+ priv->irq_flags = IRQF_SHARED;
+ priv->reg_base = base;
+
+ if (pdev->dev.of_node)
+ err = cc770_get_of_node_data(pdev, priv);
+ else if (pdev->dev.platform_data)
+ err = cc770_get_platform_data(pdev, priv);
+ else
+ err = -ENODEV;
+ if (err)
+ goto exit_free_cc770;
+
+ dev_dbg(&pdev->dev,
+ "reg_base=0x%p irq=%d clock=%d cpu_interface=0x%02x "
+ "bus_config=0x%02x clkout=0x%02x\n",
+ priv->reg_base, dev->irq, priv->can.clock.freq,
+ priv->cpu_interface, priv->bus_config, priv->clkout);
+
+ dev_set_drvdata(&pdev->dev, dev);
+ SET_NETDEV_DEV(dev, &pdev->dev);
+
+ err = register_cc770dev(dev);
+ if (err) {
+ dev_err(&pdev->dev,
+ "couldn't register CC700 device (err=%d)\n", err);
+ goto exit_free_cc770;
+ }
+
+ return 0;
+
+exit_free_cc770:
+ free_cc770dev(dev);
+exit_unmap_mem:
+ iounmap(base);
+exit_release_mem:
+ release_mem_region(mem->start, mem_size);
+
+ return err;
+}
+
+static int __devexit cc770_platform_remove(struct platform_device *pdev)
+{
+ struct net_device *dev = dev_get_drvdata(&pdev->dev);
+ struct cc770_priv *priv = netdev_priv(dev);
+ struct resource *mem;
+
+ unregister_cc770dev(dev);
+ iounmap(priv->reg_base);
+ free_cc770dev(dev);
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (mem)
+ release_mem_region(mem->start, resource_size(mem));
+ else
+ dev_err(&pdev->dev, "couldn't release mem region");
+
+ return 0;
+}
+
+static struct of_device_id __devinitdata cc770_platform_table[] = {
+ {.compatible = "bosch,cc770"}, /* CC770 from Bosch */
+ {.compatible = "intc,82527"}, /* AN82527 from Intel CP */
+ {},
+};
+
+static struct platform_driver cc770_platform_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = cc770_platform_table,
+ },
+ .probe = cc770_platform_probe,
+ .remove = __devexit_p(cc770_platform_remove),
+};
+
+static int __init cc770_platform_init(void)
+{
+ return platform_driver_register(&cc770_platform_driver);
+}
+module_init(cc770_platform_init);
+
+static void __exit cc770_platform_exit(void)
+{
+ platform_driver_unregister(&cc770_platform_driver);
+}
+module_exit(cc770_platform_exit);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next v2 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Wolfgang Grandegger @ 2011-11-25 9:43 UTC (permalink / raw)
To: netdev
Cc: Stanislav Yelenskiy, devicetree-discuss, linux-can, linuxppc-dev,
IreneV, socketcan-users
In-Reply-To: <1322214204-1121-1-git-send-email-wg@grandegger.com>
This patch enables or updates support for the CC770 and AN82527
CAN controller on the TQM8548 and TQM8xx boards.
CC: devicetree-discuss@lists.ozlabs.org
CC: linuxppc-dev@ozlabs.org
CC: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 ++++++++++++++-----
arch/powerpc/boot/dts/tqm8548.dts | 19 ++++++++++++++-----
arch/powerpc/boot/dts/tqm8xx.dts | 25 +++++++++++++++++++++++++
3 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index 9452c3c..d918752 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
- 2 0x0 0xa3000000 0x00008000 // CAN (2 x i82527)
+ 2 0x0 0xa3000000 0x00008000 // CAN (2 x CC770)
3 0x0 0xa3010000 0x00008000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 619776f..988d887 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
- 2 0x0 0xe3000000 0x00008000 // CAN (2 x i82527)
+ 2 0x0 0xe3000000 0x00008000 // CAN (2 x CC770)
3 0x0 0xe3010000 0x00008000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
index f6da7ec..c3dba25 100644
--- a/arch/powerpc/boot/dts/tqm8xx.dts
+++ b/arch/powerpc/boot/dts/tqm8xx.dts
@@ -57,6 +57,7 @@
ranges = <
0x0 0x0 0x40000000 0x800000
+ 0x3 0x0 0xc0000000 0x200
>;
flash@0,0 {
@@ -67,6 +68,30 @@
bank-width = <4>;
device-width = <2>;
};
+
+ /* Note: CAN support needs be enabled in U-Boot */
+ can@3,0 {
+ compatible = "intc,82527";
+ reg = <3 0x0 0x80>;
+ interrupts = <8 1>;
+ interrupt-parent = <&PIC>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
+ };
+
+ can@3,100 {
+ compatible = "intc,82527";
+ reg = <3 0x100 0x80>;
+ interrupts = <8 1>;
+ interrupt-parent = <&PIC>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ };
};
soc@fff00000 {
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] powerpc/40x: Add APM8018X SOC support
From: Tanmay Inamdar @ 2011-11-25 12:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <201111231415.51985.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 5743 bytes --]
Hello Arnd,
Thanks for the comments. Please see inline replies.
Regards,
Tanmay
On Wed, Nov 23, 2011 at 7:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 23 November 2011, Tanmay Inamdar wrote:
> > The AppliedMicro APM8018X embedded processor targets embedded
> applications that
> > require low power and a small footprint. It features a PowerPC 405
> processor
> > core built in a 65nm low-power CMOS process with a five-stage pipeline
> executing
> > up to one instruction per cycle. The family has 128-kbytes of on-chip
> memory,
> > a 128-bit local bus and on-chip DDR2 SDRAM controller with 16-bit
> interface.
>
> Hi Tanmay,
>
> > +#if defined(CONFIG_APM8018X)
> > +#define DCRN_CPR0_ADDR 0xa
> > +#define DCRN_CPR0_DATA 0xb
> > +#else
> > /* 440EP Clock/Power-on Reset regs */
> > #define DCRN_CPR0_ADDR 0xc
> > #define DCRN_CPR0_DATA 0xd
> > +#endif /* CONFIG_APM8018X */
>
> This prevents you from building one kernel that runs on both APM8018X and
> others. Better define a new constant name for the new registers and select
> the right one at run-time.
>
> > diff --git a/arch/powerpc/boot/dts/klondike.dts
> b/arch/powerpc/boot/dts/klondike.dts
> > new file mode 100644
> > index 0000000..9372a52
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/klondike.dts
> > @@ -0,0 +1,668 @@
> > +/*
> > + * Device Tree Source for AMCC Klondike (405)
> > + *
>
> The device tree file for the most part describes the chip, but partly also
> the board. Have you considered splitting the soc parts into a .dtsi file
> and moving all the configuration into a separate file?
>
Thanks for suggesting this. I will consider using .dtsi now.
>
>
> > diff --git a/arch/powerpc/configs/40x/klondike_defconfig
> b/arch/powerpc/configs/40x/klondike_defconfig
> > new file mode 100644
> > index 0000000..840f438
> > --- /dev/null
> > +++ b/arch/powerpc/configs/40x/klondike_defconfig
> > @@ -0,0 +1,1353 @@
> > +#
> > +# Automatically generated file; DO NOT EDIT.
> > +# Linux/powerpc 3.2.0-rc2 Kernel Configuration
> > +#
> > +# CONFIG_PPC64 is not set
> > +
>
> Please use 'make savedefconfig' to create a minimal defconfig file instead
> of listing
> the full configuration here.
>
Yes.
>
> > diff --git a/arch/powerpc/include/asm/dcr-regs.h
> b/arch/powerpc/include/asm/dcr-regs.h
> > index 380274d..c900cfd 100644
> > --- a/arch/powerpc/include/asm/dcr-regs.h
> > +++ b/arch/powerpc/include/asm/dcr-regs.h
> > @@ -24,9 +24,18 @@
> > * of the driver main register set
> > */
> >
> > +#if defined(CONFIG_APM8018X)
> > +/* CPR */
> > +#define DCRN_CPR0_CONFIG_ADDR 0xa
> > +#define DCRN_CPR1_CONFIG_DATA 0xb
> > +/* AHB */
> > +#define DCRN_SDR1_CONFIG_ADDR 0xc
> > +#define DCRN_SDR1_CONFIG_DATA 0xd
> > +#else
> > /* CPRs (440GX and 440SP/440SPe) */
> > #define DCRN_CPR0_CONFIG_ADDR 0xc
> > #define DCRN_CPR0_CONFIG_DATA 0xd
> > +#endif /* CONFIG_APM8018X */
>
> same comment as above.
>
Some existing drivers use these macros. If I change the names, I will have
to update the
driver code.
>
> > diff --git a/arch/powerpc/kernel/cputable.c
> b/arch/powerpc/kernel/cputable.c
> > index edae5bb..e5c51a6 100644
> > --- a/arch/powerpc/kernel/cputable.c
> > +++ b/arch/powerpc/kernel/cputable.c
> > @@ -1505,6 +1505,58 @@ static struct cpu_spec __initdata cpu_specs[] = {
> > .machine_check = machine_check_4xx,
> > .platform = "ppc405",
> > },
> > + { /* APM80186-SK */
> > + .pvr_mask = 0xffffffff,
> > + .pvr_value = 0x7ff11432,
>
> If you mask out the lower bits, you only need a single entry instead of
> four identical ones.
>
You are right. But each PVR represent different version of SOC. If I create
single
entry, then I will have to give generic cpu_name which I don't want.
>
> > --- a/arch/powerpc/kernel/udbg_16550.c
> > +++ b/arch/powerpc/kernel/udbg_16550.c
> > @@ -18,6 +18,19 @@ extern void real_writeb(u8 data, volatile u8 __iomem
> *addr);
> > extern u8 real_205_readb(volatile u8 __iomem *addr);
> > extern void real_205_writeb(u8 data, volatile u8 __iomem *addr);
> >
> > +#ifdef CONFIG_UART_16550_WORD_ADDRESSABLE
> > +struct NS16550 {
> > + /* this struct must be packed */
> > + unsigned char rbr; /* 0 */ u8 s0[3];
> > + unsigned char ier; /* 1 */ u8 s1[3];
> > + unsigned char fcr; /* 2 */ u8 s2[3];
> > + unsigned char lcr; /* 3 */ u8 s3[3];
> > + unsigned char mcr; /* 4 */ u8 s4[3];
> > + unsigned char lsr; /* 5 */ u8 s5[3];
> > + unsigned char msr; /* 6 */ u8 s6[3];
> > + unsigned char scr; /* 7 */ u8 s7[3];
> > +};
> > +#else
> > struct NS16550 {
> > /* this struct must be packed */
> > unsigned char rbr; /* 0 */
> > @@ -29,6 +42,7 @@ struct NS16550 {
> > unsigned char msr; /* 6 */
> > unsigned char scr; /* 7 */
> > };
> > +#endif /* CONFIG_UART_16550_WORD_ADDRESSABLE */
> >
>
> Same things as with the register definitions. Please make this
> run-time selectable to allow build-time configurations that
> support both layouts.
>
Yes. I will try to find better solution.
>
> Arnd
>
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
[-- Attachment #2: Type: text/html, Size: 7599 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Add APM8018X SOC support
From: Tanmay Inamdar @ 2011-11-25 12:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <24399FB8-956E-4C5A-B153-F77196602062@kernel.crashing.org>
Hello,
Please see inline comment.
Regards,
Tanmay
On Wed, Nov 23, 2011 at 9:46 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> On Nov 23, 2011, at 3:44 AM, Tanmay Inamdar wrote:
>
> > arch/powerpc/kernel/udbg_16550.c =A0 =A0 =A0 =A0 =A0 =A0| =A0 22 +
>
> Would be probably good to split this change into its own patch.
Sure. I will do it.
>
> - k
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains information=
=A0
that is confidential and proprietary to AppliedMicro Corporation or its s=
ubsidiaries. =
It is to be used solely for the purpose of furthering the parties' busine=
ss relationship. =
All unauthorized review, use, disclosure or distribution is prohibited. =
If you are not the intended recipient, please contact the sender by reply=
e-mail =
and destroy all copies of the original message.
=0D
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Add APM8018X SOC support
From: Arnd Bergmann @ 2011-11-25 12:53 UTC (permalink / raw)
To: Tanmay Inamdar; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <CACoXjcnfCM8Z5qFfrHtxsXkpf492LVbkDA3X=a9dRv9Lcv7Asw@mail.gmail.com>
On Friday 25 November 2011, Tanmay Inamdar wrote:
> > >
> > > +#if defined(CONFIG_APM8018X)
> > > +/* CPR */
> > > +#define DCRN_CPR0_CONFIG_ADDR 0xa
> > > +#define DCRN_CPR1_CONFIG_DATA 0xb
> > > +/* AHB */
> > > +#define DCRN_SDR1_CONFIG_ADDR 0xc
> > > +#define DCRN_SDR1_CONFIG_DATA 0xd
> > > +#else
> > > /* CPRs (440GX and 440SP/440SPe) */
> > > #define DCRN_CPR0_CONFIG_ADDR 0xc
> > > #define DCRN_CPR0_CONFIG_DATA 0xd
> > > +#endif /* CONFIG_APM8018X */
> >
> > same comment as above.
> >
>
> Some existing drivers use these macros. If I change the names, I will have
> to update the
> driver code.
Not so many apparently:
$ git grep DCRN_CPR._CONFIG
arch/powerpc/include/asm/dcr-regs.h:#define DCRN_CPR0_CONFIG_ADDR 0xc
arch/powerpc/include/asm/dcr-regs.h:#define DCRN_CPR0_CONFIG_DATA 0xd
arch/powerpc/kvm/44x_emulate.c: case DCRN_CPR0_CONFIG_ADDR:
arch/powerpc/kvm/44x_emulate.c: case DCRN_CPR0_CONFIG_DATA:
arch/powerpc/kvm/44x_emulate.c: mtdcr(DCRN_CPR0_CONFIG_ADDR,
arch/powerpc/kvm/44x_emulate.c: mfdcr(DCRN_CPR0_CONFIG_DATA));
arch/powerpc/kvm/44x_emulate.c: case DCRN_CPR0_CONFIG_ADDR:
Don't worry about out of tree drivers. If you want to be nice to the authors,
rename the macros so that the drivers break in an obvious way rather than
silently.
Note that any drivers relying on these as a constant are already broken
as soon as you try to build a kernel with both APM8018X and 440 enabled,
so you absolutely have to change the device drivers to work with those
kernels.
> > > diff --git a/arch/powerpc/kernel/cputable.c
> > b/arch/powerpc/kernel/cputable.c
> > > index edae5bb..e5c51a6 100644
> > > --- a/arch/powerpc/kernel/cputable.c
> > > +++ b/arch/powerpc/kernel/cputable.c
> > > @@ -1505,6 +1505,58 @@ static struct cpu_spec __initdata cpu_specs[] = {
> > > .machine_check = machine_check_4xx,
> > > .platform = "ppc405",
> > > },
> > > + { /* APM80186-SK */
> > > + .pvr_mask = 0xffffffff,
> > > + .pvr_value = 0x7ff11432,
> >
> > If you mask out the lower bits, you only need a single entry instead of
> > four identical ones.
> >
>
> You are right. But each PVR represent different version of SOC. If I create
> single
> entry, then I will have to give generic cpu_name which I don't want.
Isn't the common name for these always "APM80186"? If you don't need to tell
the difference between them for the purposes of cpu_spec, then don't do
it here.
Arnd
^ permalink raw reply
* Re: [RFC PATCH v5 1/9] fadump: Add documentation for firmware-assisted dump.
From: Mahesh J. Salgaonkar @ 2011-11-25 13:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, kexec, linux-kernel
In-Reply-To: <20111124223410.GB19828@bloggs.ozlabs.ibm.com>
On 11/25/2011 04:04 AM, Paul Mackerras wrote:
> On Tue, Nov 15, 2011 at 08:43:34PM +0530, Mahesh J Salgaonkar wrote:
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> Documentation for firmware-assisted dump. This document is based on the
>> original documentation written for phyp assisted dump by Linas Vepstas
>> and Manish Ahuja, with few changes to reflect the current implementation.
>>
>> Change in v3:
>> - Modified the documentation to reflect introdunction of fadump_registered
>> sysfs file and few minor changes.
>>
>> Change in v2:
>> - Modified the documentation to reflect the change of fadump_region
>> file under debugfs filesystem.
>
> In general we don't want the changes between successive versions in
> the patch description; this information should go below the "---"
> line. The patch description should describe how the patch is now and
> give any information that will be useful to someone looking at the
> resulting git commit later on, but it doesn't need to tell us about
> previous versions of the patch that will never appear in the git
> history.
Sure will do that.
>
>> +-- Once the dump is copied out, the memory that held the dump
>> + is immediately available to the running kernel. A further
>> + reboot isn't required.
>
> I have a general worry about the system making allocations that are
> intended to be node-local while it is running with restricted memory
> (i.e. after the crash and reboot and before the dump has been written
> out and the dump memory freed). Those allocations will probably all
> come from one node and thus won't necessarily be on the desired node.
> So, for very large systems with significant NUMA characteristics, it
> may be desirable (though not required) to reboot after taking the
> dump.
I have been working on trying to integrate FADUMP with the kdump
infrastructure on distros, which will modify the existing kernel initrd
to capture the vmcore and release the memory at the very early stage
before the switch_root.
However, by default FADUMP will also reboot after capturing vmcore
unless user specifies 'noreboot' option through kdump configuration file.
>
> What happens about the NUMA information in the kernel -- all the
> memory sections, etc.? Do they get set up as normal even though the
> second kernel is booting with only a small amount of memory initially?
>
In FADUMP case, the booting of second kernel after crash is equivalent
to normal kernel bootup and it boots with the knowledge of entire system
RAM with NUMA information. The memblock structure does contain map for
entire system RAM. We just reserve the memory above the bootmem at the
very early stage in the second kernel, so that it remains untouched.
Thanks,
-Mahesh.
^ permalink raw reply
* [PATCH 05/62] powerpc: remove the second argument of k[un]map_atomic()
From: Cong Wang @ 2011-11-27 5:26 UTC (permalink / raw)
To: linux-kernel
Cc: Andrea Arcangeli, Dave Carroll, Cong Wang, Marcelo Tosatti,
Alexander Graf, kvm-ppc, Paul Gortmaker, Paul Mackerras,
Avi Kivity, kvm, akpm, linuxppc-dev, Anton Blanchard,
David Gibson
In-Reply-To: <1322371662-26166-1-git-send-email-amwang@redhat.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
arch/powerpc/kvm/book3s_pr.c | 4 ++--
arch/powerpc/mm/dma-noncoherent.c | 5 ++---
arch/powerpc/mm/hugetlbpage.c | 4 ++--
arch/powerpc/mm/mem.c | 4 ++--
4 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 3c791e1..fbd4103 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -227,14 +227,14 @@ static void kvmppc_patch_dcbz(struct kvm_vcpu *vcpu, struct kvmppc_pte *pte)
hpage_offset /= 4;
get_page(hpage);
- page = kmap_atomic(hpage, KM_USER0);
+ page = kmap_atomic(hpage);
/* patch dcbz into reserved instruction, so we trap */
for (i=hpage_offset; i < hpage_offset + (HW_PAGE_SIZE / 4); i++)
if ((page[i] & 0xff0007ff) == INS_DCBZ)
page[i] &= 0xfffffff7;
- kunmap_atomic(page, KM_USER0);
+ kunmap_atomic(page);
put_page(hpage);
}
diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index 329be36..6747eec 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -365,12 +365,11 @@ static inline void __dma_sync_page_highmem(struct page *page,
local_irq_save(flags);
do {
- start = (unsigned long)kmap_atomic(page + seg_nr,
- KM_PPC_SYNC_PAGE) + seg_offset;
+ start = (unsigned long)kmap_atomic(page + seg_nr) + seg_offset;
/* Sync this buffer segment */
__dma_sync((void *)start, seg_size, direction);
- kunmap_atomic((void *)start, KM_PPC_SYNC_PAGE);
+ kunmap_atomic((void *)start);
seg_nr++;
/* Calculate next buffer segment size */
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8558b57..85d3592 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -880,9 +880,9 @@ void flush_dcache_icache_hugepage(struct page *page)
if (!PageHighMem(page)) {
__flush_dcache_icache(page_address(page+i));
} else {
- start = kmap_atomic(page+i, KM_PPC_SYNC_ICACHE);
+ start = kmap_atomic(page+i);
__flush_dcache_icache(start);
- kunmap_atomic(start, KM_PPC_SYNC_ICACHE);
+ kunmap_atomic(start);
}
}
}
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 2dd6bdd..edb8b3a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -457,9 +457,9 @@ void flush_dcache_icache_page(struct page *page)
#endif
#ifdef CONFIG_BOOKE
{
- void *start = kmap_atomic(page, KM_PPC_SYNC_ICACHE);
+ void *start = kmap_atomic(page);
__flush_dcache_icache(start);
- kunmap_atomic(start, KM_PPC_SYNC_ICACHE);
+ kunmap_atomic(start);
}
#elif defined(CONFIG_8xx) || defined(CONFIG_PPC64)
/* On 8xx there is no need to kmap since highmem is not supported */
--
1.7.4.4
^ permalink raw reply related
* [PATCH 61/62] highmem: kill all __kmap_atomic()
From: Cong Wang @ 2011-11-27 5:27 UTC (permalink / raw)
To: linux-kernel
Cc: Nicolas Pitre, linux-mips, Cong Wang, David Howells,
Paul Gortmaker, James Bottomley, Paul Mackerras, H. Peter Anvin,
sparclinux, Christoph Lameter, linux-am33-list, Russell King,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Chris Metcalf, Thomas Gleixner, linux-arm-kernel, linux-parisc,
Ralf Baechle, Kyle McMartin, Tejun Heo, akpm, Koichi Yasutake,
linuxppc-dev, David S. Miller
In-Reply-To: <1322371662-26166-1-git-send-email-amwang@redhat.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
arch/arm/mm/highmem.c | 4 ++--
arch/frv/include/asm/highmem.h | 2 +-
arch/frv/mm/highmem.c | 4 ++--
arch/mips/include/asm/highmem.h | 2 +-
arch/mips/mm/highmem.c | 4 ++--
arch/mn10300/include/asm/highmem.h | 2 +-
arch/parisc/include/asm/cacheflush.h | 2 +-
arch/powerpc/include/asm/highmem.h | 2 +-
arch/sparc/include/asm/highmem.h | 2 +-
arch/sparc/mm/highmem.c | 4 ++--
arch/tile/include/asm/highmem.h | 2 +-
arch/tile/mm/highmem.c | 4 ++--
arch/x86/include/asm/highmem.h | 2 +-
arch/x86/mm/highmem_32.c | 4 ++--
include/linux/highmem.h | 11 +++--------
15 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index 807c057..5a21505 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -36,7 +36,7 @@ void kunmap(struct page *page)
}
EXPORT_SYMBOL(kunmap);
-void *__kmap_atomic(struct page *page)
+void *kmap_atomic(struct page *page)
{
unsigned int idx;
unsigned long vaddr;
@@ -81,7 +81,7 @@ void *__kmap_atomic(struct page *page)
return (void *)vaddr;
}
-EXPORT_SYMBOL(__kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic);
void __kunmap_atomic(void *kvaddr)
{
diff --git a/arch/frv/include/asm/highmem.h b/arch/frv/include/asm/highmem.h
index a8d6565..716956a 100644
--- a/arch/frv/include/asm/highmem.h
+++ b/arch/frv/include/asm/highmem.h
@@ -157,7 +157,7 @@ static inline void kunmap_atomic_primary(void *kvaddr, enum km_type type)
pagefault_enable();
}
-void *__kmap_atomic(struct page *page);
+void *kmap_atomic(struct page *page);
void __kunmap_atomic(void *kvaddr);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/frv/mm/highmem.c b/arch/frv/mm/highmem.c
index fd7fcd4..31902c9 100644
--- a/arch/frv/mm/highmem.c
+++ b/arch/frv/mm/highmem.c
@@ -37,7 +37,7 @@ struct page *kmap_atomic_to_page(void *ptr)
return virt_to_page(ptr);
}
-void *__kmap_atomic(struct page *page)
+void *kmap_atomic(struct page *page)
{
unsigned long paddr;
int type;
@@ -64,7 +64,7 @@ void *__kmap_atomic(struct page *page)
return NULL;
}
}
-EXPORT_SYMBOL(__kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic);
void __kunmap_atomic(void *kvaddr)
{
diff --git a/arch/mips/include/asm/highmem.h b/arch/mips/include/asm/highmem.h
index 77e6440..2d91888 100644
--- a/arch/mips/include/asm/highmem.h
+++ b/arch/mips/include/asm/highmem.h
@@ -47,7 +47,7 @@ extern void kunmap_high(struct page *page);
extern void *kmap(struct page *page);
extern void kunmap(struct page *page);
-extern void *__kmap_atomic(struct page *page);
+extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern void *kmap_atomic_pfn(unsigned long pfn);
extern struct page *kmap_atomic_to_page(void *ptr);
diff --git a/arch/mips/mm/highmem.c b/arch/mips/mm/highmem.c
index 3634c7e..aff5705 100644
--- a/arch/mips/mm/highmem.c
+++ b/arch/mips/mm/highmem.c
@@ -41,7 +41,7 @@ EXPORT_SYMBOL(kunmap);
* kmaps are appropriate for short, tight code paths only.
*/
-void *__kmap_atomic(struct page *page)
+void *kmap_atomic(struct page *page)
{
unsigned long vaddr;
int idx, type;
@@ -62,7 +62,7 @@ void *__kmap_atomic(struct page *page)
return (void*) vaddr;
}
-EXPORT_SYMBOL(__kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic);
void __kunmap_atomic(void *kvaddr)
{
diff --git a/arch/mn10300/include/asm/highmem.h b/arch/mn10300/include/asm/highmem.h
index bfe2d88..7c137cd 100644
--- a/arch/mn10300/include/asm/highmem.h
+++ b/arch/mn10300/include/asm/highmem.h
@@ -70,7 +70,7 @@ static inline void kunmap(struct page *page)
* be used in IRQ contexts, so in some (very limited) cases we need
* it.
*/
-static inline unsigned long __kmap_atomic(struct page *page)
+static inline unsigned long kmap_atomic(struct page *page)
{
unsigned long vaddr;
int idx, type;
diff --git a/arch/parisc/include/asm/cacheflush.h b/arch/parisc/include/asm/cacheflush.h
index da601dd..9f21ab0 100644
--- a/arch/parisc/include/asm/cacheflush.h
+++ b/arch/parisc/include/asm/cacheflush.h
@@ -140,7 +140,7 @@ static inline void *kmap(struct page *page)
#define kunmap(page) kunmap_parisc(page_address(page))
-static inline void *__kmap_atomic(struct page *page)
+static inline void *kmap_atomic(struct page *page)
{
pagefault_disable();
return page_address(page);
diff --git a/arch/powerpc/include/asm/highmem.h b/arch/powerpc/include/asm/highmem.h
index dbc2640..caaf6e0 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -79,7 +79,7 @@ static inline void kunmap(struct page *page)
kunmap_high(page);
}
-static inline void *__kmap_atomic(struct page *page)
+static inline void *kmap_atomic(struct page *page)
{
return kmap_atomic_prot(page, kmap_prot);
}
diff --git a/arch/sparc/include/asm/highmem.h b/arch/sparc/include/asm/highmem.h
index 3d7afbb..3b6e00d 100644
--- a/arch/sparc/include/asm/highmem.h
+++ b/arch/sparc/include/asm/highmem.h
@@ -70,7 +70,7 @@ static inline void kunmap(struct page *page)
kunmap_high(page);
}
-extern void *__kmap_atomic(struct page *page);
+extern void *kmap_atomic(struct page *page);
extern void __kunmap_atomic(void *kvaddr);
extern struct page *kmap_atomic_to_page(void *vaddr);
diff --git a/arch/sparc/mm/highmem.c b/arch/sparc/mm/highmem.c
index 77140a0..055c66c 100644
--- a/arch/sparc/mm/highmem.c
+++ b/arch/sparc/mm/highmem.c
@@ -30,7 +30,7 @@
#include <asm/tlbflush.h>
#include <asm/fixmap.h>
-void *__kmap_atomic(struct page *page)
+void *kmap_atomic(struct page *page)
{
unsigned long vaddr;
long idx, type;
@@ -64,7 +64,7 @@ void *__kmap_atomic(struct page *page)
return (void*) vaddr;
}
-EXPORT_SYMBOL(__kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic);
void __kunmap_atomic(void *kvaddr)
{
diff --git a/arch/tile/include/asm/highmem.h b/arch/tile/include/asm/highmem.h
index b2a6c5d..fc8429a 100644
--- a/arch/tile/include/asm/highmem.h
+++ b/arch/tile/include/asm/highmem.h
@@ -59,7 +59,7 @@ void *kmap_fix_kpte(struct page *page, int finished);
/* This macro is used only in map_new_virtual() to map "page". */
#define kmap_prot page_to_kpgprot(page)
-void *__kmap_atomic(struct page *page);
+void *kmap_atomic(struct page *page);
void __kunmap_atomic(void *kvaddr);
void *kmap_atomic_pfn(unsigned long pfn);
void *kmap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot);
diff --git a/arch/tile/mm/highmem.c b/arch/tile/mm/highmem.c
index 31dbbd9..ef8e5a6 100644
--- a/arch/tile/mm/highmem.c
+++ b/arch/tile/mm/highmem.c
@@ -224,12 +224,12 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot)
}
EXPORT_SYMBOL(kmap_atomic_prot);
-void *__kmap_atomic(struct page *page)
+void *kmap_atomic(struct page *page)
{
/* PAGE_NONE is a magic value that tells us to check immutability. */
return kmap_atomic_prot(page, PAGE_NONE);
}
-EXPORT_SYMBOL(__kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic);
void __kunmap_atomic(void *kvaddr)
{
diff --git a/arch/x86/include/asm/highmem.h b/arch/x86/include/asm/highmem.h
index 3bd0402..302a323 100644
--- a/arch/x86/include/asm/highmem.h
+++ b/arch/x86/include/asm/highmem.h
@@ -61,7 +61,7 @@ void *kmap(struct page *page);
void kunmap(struct page *page);
void *kmap_atomic_prot(struct page *page, pgprot_t prot);
-void *__kmap_atomic(struct page *page);
+void *kmap_atomic(struct page *page);
void __kunmap_atomic(void *kvaddr);
void *kmap_atomic_pfn(unsigned long pfn);
void *kmap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot);
diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index b499626..9f85499 100644
--- a/arch/x86/mm/highmem_32.c
+++ b/arch/x86/mm/highmem_32.c
@@ -50,11 +50,11 @@ void *kmap_atomic_prot(struct page *page, pgprot_t prot)
}
EXPORT_SYMBOL(kmap_atomic_prot);
-void *__kmap_atomic(struct page *page)
+void *kmap_atomic(struct page *page)
{
return kmap_atomic_prot(page, kmap_prot);
}
-EXPORT_SYMBOL(__kmap_atomic);
+EXPORT_SYMBOL(kmap_atomic);
/*
* This is the same as kmap_atomic() but can map memory that doesn't
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 42ac049..9c1b442 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -55,12 +55,12 @@ static inline void kunmap(struct page *page)
{
}
-static inline void *__kmap_atomic(struct page *page)
+static inline void *kmap_atomic(struct page *page)
{
pagefault_disable();
return page_address(page);
}
-#define kmap_atomic_prot(page, prot) __kmap_atomic(page)
+#define kmap_atomic_prot(page, prot) kmap_atomic(page)
static inline void __kunmap_atomic(void *addr)
{
@@ -121,15 +121,10 @@ static inline void kmap_atomic_idx_pop(void)
#define NARG_(_2, _1, n, ...) n
#define NARG(...) NARG_(__VA_ARGS__, 2, 1, :)
-static inline void *kmap_atomic(struct page *page)
-{
- return __kmap_atomic(page);
-}
-
static inline void __deprecated *kmap_atomic_deprecated(struct page *page,
enum km_type km)
{
- return __kmap_atomic(page);
+ return kmap_atomic(page);
}
#define kmap_atomic1(...) kmap_atomic(__VA_ARGS__)
--
1.7.4.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