* RE: [PATCH v2] ftrace: On PowerPC we don't need frame pointers forCALLER_ADDRs
From: Usha Rani Konudula @ 2009-02-04 8:17 UTC (permalink / raw)
To: avorontsov, Steven Rostedt
Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel
In-Reply-To: <20090203145649.GA19955@oksana.dev.rtsoft.ru>
unsubscribe linux-kernel
^ permalink raw reply
* unsubscribe
From: Usha Rani Konudula @ 2009-02-04 8:11 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5 bytes --]
[-- Attachment #2: Type: text/html, Size: 3952 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
From: Jean Delvare @ 2009-02-04 7:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, ben-linux, Sean MacLennan
In-Reply-To: <1233719733.16867.171.camel@pasglop>
Hi Ben,
On Wed, 04 Feb 2009 14:55:33 +1100, Benjamin Herrenschmidt wrote:
>
> > Acked-by: Jean Delvare <khali@linux-fr.org>
>
> Jean, you'll take that in your tree or should I take it in mine ?
No, I'm not taking it, i2c-ibm_iic is under Ben Dooks' jurisdiction. So
it's up to either him or you.
--
Jean Delvare
^ permalink raw reply
* Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: wli @ 2009-02-04 6:17 UTC (permalink / raw)
To: Nick Piggin
Cc: Eli Cohen, Roland Dreier, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <200902041631.39784.nickpiggin@yahoo.com.au>
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
>>> Do the generic hugetlbfs code provides such an API ? If not, we may need
>>> to add one.
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
>> I think it's something like
>> huge_page_size(page_hstate(page))
On Wed, Feb 04, 2009 at 04:31:38PM +1100, Nick Piggin wrote:
> That would work if you have a page, yes. If you want to query which hugepage
> sizes are available, then you probably want for_each_hstate() (which is only
> within mm/hugetlb.c at the moment, but I have no objections to exporting it
> and symbols it requires).
Exciting things have happened in mm/hugetlb.c while I was out sick.
I've got quite some catching up to do.
-- wli
^ permalink raw reply
* Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: Andrew Morton @ 2009-02-04 6:26 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-dev, linux-kernel, Eli Cohen
In-Reply-To: <aday6wmn2vr.fsf@cisco.com>
On Tue, 03 Feb 2009 22:16:08 -0800 Roland Dreier <rdreier@cisco.com> wrote:
> > I think it's something like
> >
> > huge_page_size(page_hstate(page))
>
> That would suit. I assume the intention is for that to be usable by
> driver modules on any architecture?
>
erm, you overestimate the amount of planning and forethought which goes
into these things ;)
The lack of any EXPORT_SYMBOL(size_to_hstate) is a broadish hint.
^ permalink raw reply
* Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: Roland Dreier @ 2009-02-04 6:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Eli Cohen
In-Reply-To: <20090203211329.d6190a08.akpm@linux-foundation.org>
> I think it's something like
>
> huge_page_size(page_hstate(page))
That would suit. I assume the intention is for that to be usable by
driver modules on any architecture?
- R.
^ permalink raw reply
* Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: Nick Piggin @ 2009-02-04 5:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Roland Dreier, linux-kernel, Eli Cohen
In-Reply-To: <20090203211329.d6190a08.akpm@linux-foundation.org>
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote:
> On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt
> > Do the generic hugetlbfs code provides such an API ? If not, we may need
> > to add one.
>
> I think it's something like
>
> huge_page_size(page_hstate(page))
That would work if you have a page, yes. If you want to query which hugepage
sizes are available, then you probably want for_each_hstate() (which is only
within mm/hugetlb.c at the moment, but I have no objections to exporting it
and symbols it requires).
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: G4 oprofile: variable number of counters
From: Benjamin Herrenschmidt @ 2009-02-04 5:22 UTC (permalink / raw)
To: Octavian Purdila; +Cc: linuxppc-dev
In-Reply-To: <1231246535-13151-2-git-send-email-opurdila@ixiacom.com>
On Tue, 2009-01-06 at 14:55 +0200, Octavian Purdila wrote:
> For ppc750 processors which use 4 performance counters instead of the
> 6 G4 uses but otherwise is compatible with G4.
>
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
> ---
> arch/powerpc/oprofile/op_model_7450.c | 21 +++++++++++----------
> 1 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/oprofile/op_model_7450.c b/arch/powerpc/oprofile/op_model_7450.c
> index cc599eb..97348f5 100644
> --- a/arch/powerpc/oprofile/op_model_7450.c
> +++ b/arch/powerpc/oprofile/op_model_7450.c
> @@ -29,7 +29,7 @@
> static unsigned long reset_value[OP_MAX_COUNTER];
>
> static int oprofile_running;
> -static u32 mmcr0_val, mmcr1_val, mmcr2_val;
> +static u32 mmcr0_val, mmcr1_val, mmcr2_val, ctrs;
This may be static but it's still a global scope as far as kernel
symbols are concerned. Care to give it a slightly better name ? num_pmcs
would probably be already more telling.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Wire up /proc/vmallocinfo to our ioremap()
From: Benjamin Herrenschmidt @ 2009-02-04 5:18 UTC (permalink / raw)
To: linuxppc-dev, Linux Memory Management
This adds the necessary bits and pieces to powerpc implementation of
ioremap to benefit from caller tracking in /proc/vmallocinfo, at least
for ioremap's done after mem init as the older ones aren't tracked.
Note the small addition to the generic code exposing a __get_vm_area_caller()
which we need for the ppc64 implementation.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Can some mm person review the generic bit and maybe ack it ?
Cheers,
Ben.
arch/powerpc/include/asm/io.h | 6 ++++++
arch/powerpc/include/asm/machdep.h | 2 +-
arch/powerpc/mm/pgtable_32.c | 14 +++++++++++---
arch/powerpc/mm/pgtable_64.c | 25 +++++++++++++++++--------
arch/powerpc/platforms/cell/io-workarounds.c | 4 ++--
arch/powerpc/platforms/iseries/setup.c | 2 +-
include/linux/vmalloc.h | 3 +++
mm/vmalloc.c | 8 ++++++++
8 files changed, 49 insertions(+), 15 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/io.h 2009-02-04 15:37:43.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/io.h 2009-02-04 15:38:30.000000000 +1100
@@ -632,6 +632,9 @@ static inline void iosync(void)
* ioremap_flags and cannot be hooked (but can be used by a hook on one
* of the previous ones)
*
+ * * __ioremap_caller is the same as above but takes an explicit caller
+ * reference rather than using __builtin_return_address(0)
+ *
* * __iounmap, is the low level implementation used by iounmap and cannot
* be hooked (but can be used by a hook on iounmap)
*
@@ -646,6 +649,9 @@ extern void iounmap(volatile void __iome
extern void __iomem *__ioremap(phys_addr_t, unsigned long size,
unsigned long flags);
+extern void __iomem *__ioremap_caller(phys_addr_t, unsigned long size,
+ unsigned long flags, void *caller);
+
extern void __iounmap(volatile void __iomem *addr);
extern void __iomem * __ioremap_at(phys_addr_t pa, void *ea,
Index: linux-work/arch/powerpc/include/asm/machdep.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/machdep.h 2009-02-04 15:35:20.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/machdep.h 2009-02-04 15:35:25.000000000 +1100
@@ -90,7 +90,7 @@ struct machdep_calls {
void (*tce_flush)(struct iommu_table *tbl);
void __iomem * (*ioremap)(phys_addr_t addr, unsigned long size,
- unsigned long flags);
+ unsigned long flags, void *caller);
void (*iounmap)(volatile void __iomem *token);
#ifdef CONFIG_PM
Index: linux-work/arch/powerpc/mm/pgtable_32.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/pgtable_32.c 2009-02-04 15:40:22.000000000 +1100
+++ linux-work/arch/powerpc/mm/pgtable_32.c 2009-02-04 15:41:43.000000000 +1100
@@ -129,7 +129,8 @@ pgtable_t pte_alloc_one(struct mm_struct
void __iomem *
ioremap(phys_addr_t addr, unsigned long size)
{
- return __ioremap(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED);
+ return __ioremap_caller(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED,
+ __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap);
@@ -143,13 +144,20 @@ ioremap_flags(phys_addr_t addr, unsigned
/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
flags &= ~(_PAGE_USER | _PAGE_EXEC | _PAGE_HWEXEC);
- return __ioremap(addr, size, flags);
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap_flags);
void __iomem *
__ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
{
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
+}
+
+void __iomem *
+__ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
+ void *caller)
+{
unsigned long v, i;
phys_addr_t p;
int err;
@@ -212,7 +220,7 @@ __ioremap(phys_addr_t addr, unsigned lon
if (mem_init_done) {
struct vm_struct *area;
- area = get_vm_area(size, VM_IOREMAP);
+ area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (area == 0)
return NULL;
v = (unsigned long) area->addr;
Index: linux-work/arch/powerpc/mm/pgtable_64.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/pgtable_64.c 2009-02-04 15:31:20.000000000 +1100
+++ linux-work/arch/powerpc/mm/pgtable_64.c 2009-02-04 15:50:54.000000000 +1100
@@ -144,8 +144,8 @@ void __iounmap_at(void *ea, unsigned lon
unmap_kernel_range((unsigned long)ea, size);
}
-void __iomem * __ioremap(phys_addr_t addr, unsigned long size,
- unsigned long flags)
+void __iomem * __ioremap_caller(phys_addr_t addr, unsigned long size,
+ unsigned long flags, void *caller)
{
phys_addr_t paligned;
void __iomem *ret;
@@ -168,8 +168,9 @@ void __iomem * __ioremap(phys_addr_t add
if (mem_init_done) {
struct vm_struct *area;
- area = __get_vm_area(size, VM_IOREMAP,
- ioremap_bot, IOREMAP_END);
+ area = __get_vm_area_caller(size, VM_IOREMAP,
+ ioremap_bot, IOREMAP_END,
+ caller);
if (area == NULL)
return NULL;
ret = __ioremap_at(paligned, area->addr, size, flags);
@@ -186,19 +187,27 @@ void __iomem * __ioremap(phys_addr_t add
return ret;
}
+void __iomem * __ioremap(phys_addr_t addr, unsigned long size,
+ unsigned long flags)
+{
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
+}
void __iomem * ioremap(phys_addr_t addr, unsigned long size)
{
unsigned long flags = _PAGE_NO_CACHE | _PAGE_GUARDED;
+ void *caller = __builtin_return_address(0);
if (ppc_md.ioremap)
- return ppc_md.ioremap(addr, size, flags);
- return __ioremap(addr, size, flags);
+ return ppc_md.ioremap(addr, size, flags, caller);
+ return __ioremap_caller(addr, size, flags, caller);
}
void __iomem * ioremap_flags(phys_addr_t addr, unsigned long size,
unsigned long flags)
{
+ void *caller = __builtin_return_address(0);
+
/* writeable implies dirty for kernel addresses */
if (flags & _PAGE_RW)
flags |= _PAGE_DIRTY;
@@ -207,8 +216,8 @@ void __iomem * ioremap_flags(phys_addr_t
flags &= ~(_PAGE_USER | _PAGE_EXEC);
if (ppc_md.ioremap)
- return ppc_md.ioremap(addr, size, flags);
- return __ioremap(addr, size, flags);
+ return ppc_md.ioremap(addr, size, flags, caller);
+ return __ioremap_caller(addr, size, flags, caller);
}
Index: linux-work/arch/powerpc/platforms/cell/io-workarounds.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/cell/io-workarounds.c 2009-02-04 15:36:48.000000000 +1100
+++ linux-work/arch/powerpc/platforms/cell/io-workarounds.c 2009-02-04 15:51:27.000000000 +1100
@@ -131,10 +131,10 @@ static const struct ppc_pci_io __devinit
};
static void __iomem *iowa_ioremap(phys_addr_t addr, unsigned long size,
- unsigned long flags)
+ unsigned long flags, void *caller)
{
struct iowa_bus *bus;
- void __iomem *res = __ioremap(addr, size, flags);
+ void __iomem *res = __ioremap_caller(addr, size, flags, caller);
int busno;
bus = iowa_pci_find(0, (unsigned long)addr);
Index: linux-work/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/iseries/setup.c 2009-02-04 15:39:22.000000000 +1100
+++ linux-work/arch/powerpc/platforms/iseries/setup.c 2009-02-04 15:39:28.000000000 +1100
@@ -617,7 +617,7 @@ static void iseries_dedicated_idle(void)
}
static void __iomem *iseries_ioremap(phys_addr_t address, unsigned long size,
- unsigned long flags)
+ unsigned long flags, void *caller)
{
return (void __iomem *)address;
}
Index: linux-work/include/linux/vmalloc.h
===================================================================
--- linux-work.orig/include/linux/vmalloc.h 2009-02-04 15:33:35.000000000 +1100
+++ linux-work/include/linux/vmalloc.h 2009-02-04 15:33:47.000000000 +1100
@@ -84,6 +84,9 @@ extern struct vm_struct *get_vm_area_cal
unsigned long flags, void *caller);
extern struct vm_struct *__get_vm_area(unsigned long size, unsigned long flags,
unsigned long start, unsigned long end);
+extern struct vm_struct *__get_vm_area_caller(unsigned long size, unsigned long flags,
+ unsigned long start, unsigned long end,
+ void *caller);
extern struct vm_struct *get_vm_area_node(unsigned long size,
unsigned long flags, int node,
gfp_t gfp_mask);
Index: linux-work/mm/vmalloc.c
===================================================================
--- linux-work.orig/mm/vmalloc.c 2009-02-04 15:32:47.000000000 +1100
+++ linux-work/mm/vmalloc.c 2009-02-04 15:33:25.000000000 +1100
@@ -1106,6 +1106,14 @@ struct vm_struct *__get_vm_area(unsigned
}
EXPORT_SYMBOL_GPL(__get_vm_area);
+struct vm_struct *__get_vm_area_caller(unsigned long size, unsigned long flags,
+ unsigned long start, unsigned long end,
+ void *caller)
+{
+ return __get_vm_area_node(size, flags, start, end, -1, GFP_KERNEL,
+ caller);
+}
+
/**
* get_vm_area - reserve a contiguous kernel virtual area
* @size: size of the area
^ permalink raw reply
* Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: Andrew Morton @ 2009-02-04 5:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Eli Cohen, Roland Dreier, linux-kernel, linuxppc-dev
In-Reply-To: <1233712248.16867.131.camel@pasglop>
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote:
> > Forwarding Eli's patch below, since PowerPC guys may have missed it. I
> > guess the question for Ben et al is whether there is any issue with
> > exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
> > it's an internal detail). It would probably make sense to roll this
> > change into the mlx4 change that Eli alludes to below and merge through
> > my tree (with ppc maintainer acks of course), rather than splitting this
> > patch out and introducing cross-tree dependencies (and also separating
> > the rationale for the change from the change itself).
> >
> > Thanks,
> > Roland
> >
> >
> > Drivers may want to take advantage of the large pages used for memory obtained
> > from hugetlbfs. One example is mlx4_ib which can use much less MTT entries (in
> > the order of HPAGE_SIZE / PAGE_SIZE) when registering such memory, thus scale
> > significantly better when registering larger memory regions. Other drivers
> > could also benefit from this.
>
> Except that we support multiple large page sizes nowadays ... I think
> the size can be specified per mountpoint of hugetlbfs no ? Thus things
> like mellanox would have to query the page size used for a given
> mapping.
>
> Do the generic hugetlbfs code provides such an API ? If not, we may need
> to add one.
>
I think it's something like
huge_page_size(page_hstate(page))
^ permalink raw reply
* Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
From: Benjamin Herrenschmidt @ 2009-02-04 4:43 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, wd, dzu
In-Reply-To: <1231505915-16082-1-git-send-email-yanok@emcraft.com>
On Fri, 2009-01-09 at 15:58 +0300, Ilya Yanok wrote:
> This patch rewrites consistent dma allocations support to use vmalloc
> layer to allocate virtual memory space from vmalloc pool and get rid
> of CONFIG_CONSISTENT_{START,SIZE}.
So as commented before, please drop the defconfig updates.
I'm happy with the idea but I have a few nits with the implementation:
> -/*
> * Allocate DMA-coherent memory space and return both the kernel remapped
> * virtual and bus address for that space.
> */
> @@ -151,19 +41,17 @@ void *
> __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
> {
> struct page *page;
> - struct vm_region *c;
> unsigned long order;
> + void *v;
> + int i;
> + struct page *pages[PAGE_ALIGN(size)>>PAGE_SHIFT];
I'm not -too- fan of that page list one the stack up there.
I understand why you don't wantto kmalloc something here etc... but
that's what __vmalloc_area() does and it's somewhat useful to keep track
of the page array that way, it might prove handy in the future.
Might even be worth adding a generic patch to add a VM_COHERENT_DMA flag
so they can be listed as such and make sure you set the "caller" field
yourself with your own caller.
(Hint: look at the output of /proc/vmallocinfo)
Also, the mucking around with PG_Reserved shouldn't be of any use
anymore.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] Check name property to determine partition nodes.
From: Benjamin Herrenschmidt @ 2009-02-04 4:09 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev, vwool, linux-mtd, David Woodhouse, dwg
In-Reply-To: <20090123161805.GA2598@codiert.org>
On Fri, 2009-01-23 at 17:18 +0100, Benjamin Krill wrote:
> SLOF has a further node which could not be evaluate
> by the current routine. The current routine returns
> because the node hasn't the required reg property. As
> fix this patch adds a check to determine the partition
> child nodes. If the node is not an partition the number
> of total partitions will be decreased and loop continue
> with the next nodes.
Somebody on the MTD list is taking that ? David ? Or should I merge it
via powerpc ?
Cheers,
Ben.
> Signed-off-by: Benjamin Krill <ben@codiert.org>
> ---
> drivers/mtd/ofpart.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> index 9e45b3f..3e164f0 100644
> --- a/drivers/mtd/ofpart.c
> +++ b/drivers/mtd/ofpart.c
> @@ -46,6 +46,13 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
> const u32 *reg;
> int len;
>
> + /* check if this is a partition node */
> + partname = of_get_property(pp, "name", &len);
> + if (strcmp(partname, "partition") != 0) {
> + nr_parts--;
> + continue;
> + }
> +
> reg = of_get_property(pp, "reg", &len);
> if (!reg || (len != 2 * sizeof(u32))) {
> of_node_put(pp);
^ permalink raw reply
* Re: [PATCH] powerpc: use common cpu_die
From: Benjamin Herrenschmidt @ 2009-02-04 4:07 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <1231160724_126472@mercury.realtime.net>
> --- work.git.orig/arch/powerpc/platforms/powermac/setup.c 2009-01-05 02:09:08.000000000 -0600
> +++ work.git/arch/powerpc/platforms/powermac/setup.c 2009-01-05 02:27:23.000000000 -0600
> @@ -672,7 +672,7 @@ static int pmac_pci_probe_mode(struct pc
> /* access per cpu vars from generic smp.c */
> DECLARE_PER_CPU(int, cpu_state);
>
> -static void pmac_cpu_die(void)
> +static void pmac64_cpu_die(void)
> {
> /*
.../...
> --- work.git.orig/arch/powerpc/platforms/powermac/smp.c 2009-01-05 02:09:08.000000000 -0600
> +++ work.git/arch/powerpc/platforms/powermac/smp.c 2009-01-05 02:27:23.000000000 -0600
.../...
>
> -void cpu_die(void)
> +void pmac32_cpu_die(void)
> {
> local_irq_disable();
> cpu_dead[smp_processor_id()] = 1;
Hi Milton ! Any chance you can move both pmac32 and pmac64 variants into
the same file ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
From: Benjamin Herrenschmidt @ 2009-02-04 3:55 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, ben-linux, Sean MacLennan
In-Reply-To: <20090202182909.2cea69a3@hyperion.delvare>
> Acked-by: Jean Delvare <khali@linux-fr.org>
Jean, you'll take that in your tree or should I take it in mine ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 2/4] Generic device tree for all AmigaOne boards
From: Benjamin Herrenschmidt @ 2009-02-04 3:51 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev list
In-Reply-To: <20090202213913.258290@gmx.net>
On Mon, 2009-02-02 at 22:39 +0100, Gerhard Pircher wrote:
> This device tree does not provide the correct CPU name, as various CPU
> models and revisions are used in AmigaOnes. Also the PCI root node does
> not contain a interrupt mapping property, as all boards have different
> interrupt routing. However the kernel can do a 1:1 mapping of all PCI
> interrupts, as only i8259 legacy interrupts are used.
Looks ok for the purpose, but please remove the commented bits etc...
Ben.
> Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
> ---
> arch/powerpc/boot/dts/amigaone.dts | 183 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 183 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/amigaone.dts
>
> diff --git a/arch/powerpc/boot/dts/amigaone.dts b/arch/powerpc/boot/dts/amigaone.dts
> new file mode 100644
> index 0000000..54d49e0
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/amigaone.dts
> @@ -0,0 +1,183 @@
> +/*
> + * AmigaOne Device Tree Source
> + *
> + * Copyright 2008 Gerhard Pircher (gerhard_pircher@gmx.net)
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "AmigaOne";
> + compatible = "eyetech,amigaone";
> + coherency-off;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #cpus = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <32768>; // L1, 32K
> + i-cache-size = <32768>; // L1, 32K
> + timebase-frequency = <0>; // 33.3 MHz, from U-boot
> + clock-frequency = <0>; // From U-boot
> + bus-frequency = <0>; // From U-boot
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0>; // From U-boot
> + };
> +
> + pci@80000000 {
> + device_type = "pci";
> + compatible = "mai-logic,articia-s";
> + bus-frequency = <33333333>;
> + bus-range = <0 0xff>;
> + ranges = <0x01000000 0 0x00000000 0xfe000000 0 0x00c00000 // PCI I/O
> + 0x02000000 0 0x80000000 0x80000000 0 0x7d000000 // PCI memory
> + 0x02000000 0 0x00000000 0xfd000000 0 0x01000000>; // PCI alias memory (ISA)
> + 8259-interrupt-acknowledge = <0xfef00000>;
> + // Do not define a interrupt-parent here, if there is no
> + // interrupt-map property.
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + isa@7 {
> + device_type = "isa";
> + compatible = "pciclass,0601";
> + vendor-id = <0x00001106>;
> + device-id = <0x00000686>;
> + revision-id = <0x00000010>;
> + class-code = <0x00060100>;
> + subsystem-id = <0>;
> + subsystem-vendor-id = <0>;
> + devsel-speed = <0x00000001>;
> + min-grant = <0>;
> + max-latency = <0>;
> + /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
> + ranges = <0x00000001 0 0x01000000 0 0x00000000 0x00010000>;
> + interrupt-parent = <&i8259>;
> + #interrupt-cells = <2>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + dma-controller@0 {
> + compatible = "pnpPNP,200";
> + reg = <1 0x00000000 0x00000020
> + 1 0x00000080 0x00000010
> + 1 0x000000c0 0x00000020>;
> + /* Channel 4 reserverd, cascade mode, 2x32k transfer/counter
> + * widths and bus master capability.
> + */
> +/* dma = <0x4 0x4 0x20 0x20 0x1>; */
> + };
> +
> + i8259: interrupt-controller@20 {
> + device_type = "interrupt-controller";
> + compatible = "pnpPNP,000";
> + interrupt-controller;
> + reg = <1 0x00000020 0x00000002
> + 1 0x000000a0 0x00000002
> + 1 0x000004d0 0x00000002>;
> + reserved-interrupts = <2>;
> + #interrupt-cells = <2>;
> + };
> +
> + timer@40 {
> + // Also adds pcspkr to platform devices.
> + compatible = "pnpPNP,100";
> + reg = <1 0x00000040 0x00000020>;
> + };
> +
> + 8042@60 {
> + device_type = "8042";
> + reg = <1 0x00000060 0x00000001
> + 1 0x00000064 0x00000001>;
> + // IRQ1, IRQ12 (rising edge)
> + interrupts = <1 3 12 3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + keyboard@0 {
> + compatible = "pnpPNP,303";
> + reg = <0>;
> + };
> +
> + mouse@1 {
> + compatible = "pnpPNP,f03";
> + reg = <1>;
> + };
> + };
> +
> + rtc@70 {
> + compatible = "pnpPNP,b00";
> + reg = <1 0x00000070 0x00000002>;
> + interrupts = <8 3>;
> + };
> +
> + serial@3f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501","pnpPNP,500";
> + reg = <1 0x000003f8 0x00000008>;
> + // IRQ4 (rising edge)
> + interrupts = <4 3>;
> + clock-frequency = <1843200>;
> + current-speed = <115200>;
> + };
> +
> + serial@2f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501","pnpPNP,500";
> + reg = <1 0x000002f8 0x00000008>;
> + // IRQ3 (rising edge)
> + interrupts = <3 3>;
> + clock-frequency = <1843200>;
> + current-speed = <115200>;
> + };
> +
> + parallel@378 {
> + device_type = "parallel";
> + // No ECP support for now, otherwise add "pnpPNP,401".
> + compatible = "pnpPNP,400";
> + reg = <1 0x00000378 0x00000003
> + 1 0x00000778 0x00000003>;
> +/* interrupts = <7 0>; */
> + // Parallel port DMA mode unknown.
> +/* dma = <0x3 0x0 0x0 0x0>; */
> + };
> +
> + fdc@3f0 {
> + device_type = "fdc";
> + compatible = "pnpPNP,700";
> + reg = <1 0x000003f0 0x00000008>;
> + // IRQ6 (rising edge)
> + interrupts = <6 3>;
> + // Floppy DMA mode unknown.
> +/* dma = < >; */
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + disk@0 {
> + reg = <0>;
> + };
> + };
> + };
> + };
> +
> + chosen {
> + linux,stdout-path = "/pci@80000000/isa@7/serial@3f8";
> + };
> +};
> --
> 1.5.3.4
>
>
^ permalink raw reply
* Re: [PATCH v2 1/4] Add platform support for AmigaOne
From: Benjamin Herrenschmidt @ 2009-02-04 3:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev list
In-Reply-To: <20090202213910.258290@gmx.net>
> + hose->first_busno = bus_range ? bus_range[0] : 0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> +
> + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0);
Minor in the context of amigaone but still... the above should come from
the device-tree... I suppose those are really just IO space addresses
cf8 and cfc, in which case, an option is to call that first:
> + /* Interpret the "ranges" property */
> + /* This also maps the I/O region and sets isa_io/mem_base */
> + pci_process_bridge_OF_ranges(hose, dev, 1);
And -then- use hose->io_resource.start + 0xcf8 / 0xcfc, the later can be
hard coded as they are pretty standard values.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Ignore vmlinux.strip
From: Benjamin Herrenschmidt @ 2009-02-04 3:42 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090128145057.7ff2d12a@lappy.seanm.ca>
On Wed, 2009-01-28 at 14:50 -0500, Sean MacLennan wrote:
> Not sure if this is PPC specific or not. I use the following patch to
> get a clean git status. Does nobody else see this file? Or am I missing
> a step somewhere?
Looks good actually.
> Cheers,
> Sean
>
> Ignore the vmlinux.strip file.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> diff --git a/.gitignore b/.gitignore
> index 869e1a3..f7e924a 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -32,6 +32,7 @@
> tags
> TAGS
> vmlinux
> +vmlinux.strip
> System.map
> Module.markers
> Module.symvers
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Benjamin Herrenschmidt @ 2009-02-04 3:39 UTC (permalink / raw)
To: Nathan Lynch; +Cc: containers, linuxppc-dev
In-Reply-To: <1233182478-27113-2-git-send-email-ntl@pobox.com>
> +struct cr_hdr_cpu {
> + struct pt_regs pt_regs;
> + /* relevant fields from thread_struct */
> + double fpr[32][TS_FPRWIDTH];
> + unsigned int fpscr;
> + int fpexc_mode;
> + /* unsigned int align_ctl; this is never updated? */
> + unsigned long dabr;
> +};
Is there some version or other identification somewhere ? If not there
should be. ie, we're going to add things here. For example, what about
the vector registers ? Also, some CPUs will have more HW debug registers
than just the DABR (we plan to add support for all the BookE architected
IACs and DACs for example), etc...
Ben.
^ permalink raw reply
* Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: Benjamin Herrenschmidt @ 2009-02-04 1:50 UTC (permalink / raw)
To: Roland Dreier; +Cc: Eli Cohen, linux-kernel, linuxppc-dev
In-Reply-To: <ada8wonnh3t.fsf@cisco.com>
On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote:
> Forwarding Eli's patch below, since PowerPC guys may have missed it. I
> guess the question for Ben et al is whether there is any issue with
> exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
> it's an internal detail). It would probably make sense to roll this
> change into the mlx4 change that Eli alludes to below and merge through
> my tree (with ppc maintainer acks of course), rather than splitting this
> patch out and introducing cross-tree dependencies (and also separating
> the rationale for the change from the change itself).
>
> Thanks,
> Roland
>
>
> Drivers may want to take advantage of the large pages used for memory obtained
> from hugetlbfs. One example is mlx4_ib which can use much less MTT entries (in
> the order of HPAGE_SIZE / PAGE_SIZE) when registering such memory, thus scale
> significantly better when registering larger memory regions. Other drivers
> could also benefit from this.
Except that we support multiple large page sizes nowadays ... I think
the size can be specified per mountpoint of hugetlbfs no ? Thus things
like mellanox would have to query the page size used for a given
mapping.
Do the generic hugetlbfs code provides such an API ? If not, we may need
to add one.
Cheers,
Ben.
> Signed-off-by: Eli Cohen <eli@mellanox.co.il>
> ---
> arch/powerpc/mm/hash_utils_64.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 8d5b475..6cff8c7 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -104,6 +104,7 @@ int mmu_highuser_ssize = MMU_SEGSIZE_256M;
> u16 mmu_slb_size = 64;
> #ifdef CONFIG_HUGETLB_PAGE
> unsigned int HPAGE_SHIFT;
> +EXPORT_SYMBOL(HPAGE_SHIFT);
> #endif
> #ifdef CONFIG_PPC_64K_PAGES
> int mmu_ci_restrictions;
^ permalink raw reply
* Re: [PATCH 0/6] USB: Fixes for fsl_qe_udc driver
From: Greg KH @ 2009-02-04 1:27 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, linux-usb, linux-kernel Kernel, linuxppc-dev list,
Alan Stern, Andrew Morton, Li Yang, Timur Tabi
In-Reply-To: <20090202155004.GA6764@oksana.dev.rtsoft.ru>
On Mon, Feb 02, 2009 at 06:50:04PM +0300, Anton Vorontsov wrote:
> On Tue, Jan 13, 2009 at 08:40:01AM -0800, Greg KH wrote:
> > On Tue, Jan 13, 2009 at 09:49:39AM -0600, Kumar Gala wrote:
> > > On Jan 6, 2009, at 10:53 PM, Greg KH wrote:
> > >> On Tue, Jan 06, 2009 at 10:44:13PM -0600, Kumar Gala wrote:
> > >>> On Dec 25, 2008, at 8:14 AM, Anton Vorontsov wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> Just resending some fixes that seem to be lost...
> > >>>
> > >>> Greg,
> > >>>
> > >>> What happened w/this patch set?
> > >>
> > >> As it was sent during the hollidays (on Christmas day at that), it's
> > >> still in my "to-review" queue. I'll get to it in a few days after I
> > >> resync the USB tree with Linus.
> > >
> > > Any update on the review of these 6 patches?
> >
> > It's in my queue, been busy with "real work" for a bit right now,
> > sorry...
>
> Hello Greg,
>
> Can you please look into these patches? I think they all are 2.6.29
> material, since the QE UDC driver is barely usable w/o these fixes.
My appologies, I've now applied them all and will queue them up to Linus
before .29 is out.
thanks,
greg k-h
^ permalink raw reply
* FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
From: Roland Dreier @ 2009-02-04 1:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Eli Cohen; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090203164930.GA10101@mtls03>
Forwarding Eli's patch below, since PowerPC guys may have missed it. I
guess the question for Ben et al is whether there is any issue with
exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
it's an internal detail). It would probably make sense to roll this
change into the mlx4 change that Eli alludes to below and merge through
my tree (with ppc maintainer acks of course), rather than splitting this
patch out and introducing cross-tree dependencies (and also separating
the rationale for the change from the change itself).
Thanks,
Roland
Drivers may want to take advantage of the large pages used for memory obtained
from hugetlbfs. One example is mlx4_ib which can use much less MTT entries (in
the order of HPAGE_SIZE / PAGE_SIZE) when registering such memory, thus scale
significantly better when registering larger memory regions. Other drivers
could also benefit from this.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
---
arch/powerpc/mm/hash_utils_64.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 8d5b475..6cff8c7 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -104,6 +104,7 @@ int mmu_highuser_ssize = MMU_SEGSIZE_256M;
u16 mmu_slb_size = 64;
#ifdef CONFIG_HUGETLB_PAGE
unsigned int HPAGE_SHIFT;
+EXPORT_SYMBOL(HPAGE_SHIFT);
#endif
#ifdef CONFIG_PPC_64K_PAGES
int mmu_ci_restrictions;
--
1.6.1
^ permalink raw reply related
* Re: Booting 2.6.29-rc3 on mpc8661d_hpcn failing
From: Benjamin Herrenschmidt @ 2009-02-04 0:47 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev list
In-Reply-To: <498867C0.2000607@gefanuc.com>
On Tue, 2009-02-03 at 15:50 +0000, Martyn Welch wrote:
>
> The primary CPU is spinning in smp_generic_give_timebase() waiting for
> "!tbsync->ack". The secondary CPU has made it into
> smp_generic_take_timebase() and has apparently (according to some
> printk's I put in there) set "tbsync->ack=1". After that I don't get
> any printk's, I guess that the one I have put in the "!
> tbsync->handshake" while loop is making it to the print buffer, but
> with both processors spinning it's not getting to the serial console.
>
> At a guess, given that commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744
> seems to be the point that it stopped working correctly, that "tbsync"
> is now somehow becoming cached?
>
Maybe we are missing the M bit in the mapping ?
Let's see... the kernel mapping is done via BATs on those guys (ie, e600
is a hash table based processor right ? some kind of 74xx). The code
that sets them up is in
arch/powerpc/mm/ppc_mmu_32.c
In mmu_mapin_ram() we call setbat() multiple times. The last argument is
the "flags" which is set to _PAGE_RAM. That should contain
_PAGE_COHERENT when CONFIG_SMP is set unless I screwed up. IE. _PAGE_RAM
is _PAGE_KERNEL | _PAGE_HWEXEC. _PAGE_KERNEL is _PAGE_BASE plus things,
and _PAGE_BASE should contains _PAGE_COHERENT if CONFIG_SMP or
CONFIG_PPC_STD_MMU are set and they should both be in your case.
setbat() itself will clear _PAGE_COHERENT under some circumstances
however. Either if the flags contain _PAGE_NO_CACHE, which should not be
the case here, or if the CPU feature bit CPU_FTR_NEED_COHERENT is -not-
set. I think that could be the cause of the problem.
CPU_FTR_NEED_COHERENT is set as part of CPU_FTR_COMMON if CONFIG_SMP
is set (among other things). So it -should- be set for you. since
CPU_FTR_COMMON should be OR'ed with all CPU table entries.
So I'm a bit at a loss here... unless something else went wrong.
Please let me know what you find out.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
From: Benjamin Herrenschmidt @ 2009-02-04 0:34 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, Steven Rostedt, Paul Mackerras, Ingo Molnar,
linux-kernel
In-Reply-To: <20090203185933.GA9878@oksana.dev.rtsoft.ru>
On Tue, 2009-02-03 at 21:59 +0300, Anton Vorontsov wrote:
> On Tue, Feb 03, 2009 at 11:32:18AM -0500, Steven Rostedt wrote:
> >
> > On Tue, 2009-02-03 at 19:19 +0300, Anton Vorontsov wrote:
> > > On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote:
> >
> > > [1] Btw, why exactly do we need the -fno-omit-frame-pointer for
> > > "FUNCTION_TRCER" tracer? Why just -pg isn't sufficient?..
> > >
> >
> > The problem is this that is in the toplevel Makefile:
> >
> >
> > ifdef CONFIG_FRAME_POINTER
> > KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
> > else
> > KBUILD_CFLAGS += -fomit-frame-pointer
> > endif
> >
And don't forget the gcc bug that miscompiles function epilogues on ppc
with -fno-omit-frame-pointer (iirc), which we need to work around using
-mno-sched-epilog.
Currently, we set that only if CONFIG_FUNCTION_TRACER is set, ie, we
assume that we only set -fno-omit-frame-pointer when
CONFIG_FUNCTION_TRACER is set.
Ben.
^ permalink raw reply
* Re: [PATCH v2] Add support for the digsy MTC board.
From: Grant Likely @ 2009-02-03 21:02 UTC (permalink / raw)
To: Grzegorz Bernacki; +Cc: linuxppc-dev
In-Reply-To: <498806CF.3030004@semihalf.com>
On Tue, Feb 3, 2009 at 1:56 AM, Grzegorz Bernacki <gjb@semihalf.com> wrote:
> Grant Likely wrote:
>> Hey Grzegorz,
>>
>> I've pulled your patch into my -next tree, but I made a few changes first:
>> - I dropped the defconfig changes because they conflict with the
>> defconfig update that Ben just pulled from me
>> - I updated the .dts file to reflect changes I was already making to
>> all the other .dts files
>> - I added the digsy-mtc board to the Kconfig documentation.
>>
>> I've pushed my whole queue of changes out to my -next tree. Please
>> pull it down and try it out. (Note, this tree will get rebased at
>> least once before I ask Ben to pull it, so be aware). Make sure that
>> I haven't broken your .dts file. To get the defconfig change in, you
>> can either send me another patch with just the defconfig change, or
>> you can pop my version of your patch off the top of my -next tree and
>> rebase your entire patch on top it. Whatever you prefer.
>>
>> One more note; the new digsy-mtc.dts file from my tree will probably
>> not work with older kernels. Kernels need to be backward compatible
>> with older .dts files, but the same is not true for the other way
>> around.
>>
>> Here's my -next tree:
>>
>> git://git.secretlab.ca/git/linux-2.6-mpc52xx next
>>
>
> Hi Grant,
>
> Thanks for pulling and updating my patch.
> I got your tree and now I try to build kernel image for digsy, but I get
> following errors:
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c:77: error: field 'of_gc' has incomplete type
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_gpt_gpio_setup':arch/powerpc/platforms/52xx/mpc52xx_gpt.c:350: error: parameter name omitted
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c:350: error: parameter name omitted
>
> They disappear when I add support for OF gpio, but I think that parts of
> mpc52xx_gpt.c file should be inside '#ifdef CONFIG_OF_GPIO' clause.
Good catch. Thanks.
I've fixed the patch and I'll repost and refresh my tree shortly.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/44x: Fix address decoding setup of PCI 2.x cells
From: Benjamin Herrenschmidt @ 2009-02-03 20:55 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.0902031616130.21407@vixen.sonytel.be>
> Could it be my USB failures were due to the PPC440 USB host needing the various
> CONFIG*USB*BIG_ENDIAN* options, which may conflict with USB hosts on PCI
> plug-in cards?
>
> The E1000 did work fine.
You need to enable support for both endians, that's supposed to work.
Ben.
^ permalink raw reply
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