* [PATCH 8/8] Cell IOMMU fixed mapping support
From: Michael Ellerman @ 2008-01-30 0:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <1cbc0deea968ece13756e3c86ec3af0b7586b80b.1201616038.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 11167 bytes --]
This patch adds support for setting up a fixed IOMMU mapping on certain
cell machines. For 64-bit devices this avoids the performance overhead of
mapping and unmapping pages at runtime. 32-bit devices are unable to use
the fixed mapping.
The fixed mapping is established at boot, and maps all of physical memory
1:1 into device space at some offset. On machines with < 30 GB of memory
we setup the fixed mapping immediately above the normal IOMMU window.
For example a machine with 4GB of memory would end up with the normal
IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In
this case a 64-bit device wishing to DMA to 1GB would be told to DMA to
3GB, plus any offset required by firmware. The firmware offset is encoded
in the "dma-ranges" property.
On machines with 30GB or more of memory, we are unable to place the fixed
mapping above the normal IOMMU window as we would run out of address space.
Instead we move the normal IOMMU window to coincide with the hash page
table, this region does not need to be part of the fixed mapping as no
device should ever be DMA'ing to it. We then setup the fixed mapping
from 0 to 32GB.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 269 ++++++++++++++++++++++++++++++++++-
1 files changed, 267 insertions(+), 2 deletions(-)
Updated to include a description in the file.
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 3baade1..68274a0 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -1,7 +1,7 @@
/*
* IOMMU implementation for Cell Broadband Processor Architecture
*
- * (C) Copyright IBM Corporation 2006
+ * (C) Copyright IBM Corporation 2006-2008
*
* Author: Jeremy Kerr <jk@ozlabs.org>
*
@@ -523,6 +523,9 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_direct_offset;
+static unsigned long dma_iommu_fixed_base;
+struct dma_mapping_ops dma_iommu_fixed_ops;
+
static void cell_dma_dev_setup_iommu(struct device *dev)
{
struct iommu_window *window;
@@ -545,11 +548,16 @@ static void cell_dma_dev_setup_iommu(struct device *dev)
archdata->dma_data = &window->table;
}
+static void cell_dma_dev_setup_static(struct device *dev);
+
static void cell_dma_dev_setup(struct device *dev)
{
struct dev_archdata *archdata = &dev->archdata;
- if (get_pci_dma_ops() == &dma_iommu_ops)
+ /* Order is important here, these are not mutually exclusive */
+ if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
+ cell_dma_dev_setup_static(dev);
+ else if (get_pci_dma_ops() == &dma_iommu_ops)
cell_dma_dev_setup_iommu(dev);
else if (get_pci_dma_ops() == &dma_direct_ops)
archdata->dma_data = (void *)cell_dma_direct_offset;
@@ -752,6 +760,260 @@ static int __init cell_iommu_init_disabled(void)
return 0;
}
+/*
+ * Fixed IOMMU mapping support
+ *
+ * This code adds support for setting up a fixed IOMMU mapping on certain
+ * cell machines. For 64-bit devices this avoids the performance overhead of
+ * mapping and unmapping pages at runtime. 32-bit devices are unable to use
+ * the fixed mapping.
+ *
+ * The fixed mapping is established at boot, and maps all of physical memory
+ * 1:1 into device space at some offset. On machines with < 30 GB of memory
+ * we setup the fixed mapping immediately above the normal IOMMU window.
+ *
+ * For example a machine with 4GB of memory would end up with the normal
+ * IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In
+ * this case a 64-bit device wishing to DMA to 1GB would be told to DMA to
+ * 3GB, plus any offset required by firmware. The firmware offset is encoded
+ * in the "dma-ranges" property.
+ *
+ * On machines with 30GB or more of memory, we are unable to place the fixed
+ * mapping above the normal IOMMU window as we would run out of address space.
+ * Instead we move the normal IOMMU window to coincide with the hash page
+ * table, this region does not need to be part of the fixed mapping as no
+ * device should ever be DMA'ing to it. We then setup the fixed mapping
+ * from 0 to 32GB.
+ */
+
+static u64 cell_iommu_get_fixed_address(struct device *dev)
+{
+ u64 cpu_addr, size, best_size, pci_addr = OF_BAD_ADDR;
+ struct device_node *tmp, *np;
+ const u32 *ranges = NULL;
+ int i, len, best;
+
+ np = dev->archdata.of_node;
+ of_node_get(np);
+ ranges = of_get_property(np, "dma-ranges", &len);
+ while (!ranges && np) {
+ tmp = of_get_parent(np);
+ of_node_put(np);
+ np = tmp;
+ ranges = of_get_property(np, "dma-ranges", &len);
+ }
+
+ if (!ranges) {
+ dev_dbg(dev, "iommu: no dma-ranges found\n");
+ goto out;
+ }
+
+ len /= sizeof(u32);
+
+ /* dma-ranges format:
+ * 1 cell: pci space
+ * 2 cells: pci address
+ * 2 cells: parent address
+ * 2 cells: size
+ */
+ for (i = 0, best = -1, best_size = 0; i < len; i += 7) {
+ cpu_addr = of_translate_dma_address(np, ranges +i + 3);
+ size = of_read_number(ranges + i + 5, 2);
+
+ if (cpu_addr == 0 && size > best_size) {
+ best = i;
+ best_size = size;
+ }
+ }
+
+ if (best >= 0)
+ pci_addr = of_read_number(ranges + best + 1, 2);
+ else
+ dev_dbg(dev, "iommu: no suitable range found!\n");
+
+out:
+ of_node_put(np);
+
+ return pci_addr;
+}
+
+static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
+{
+ if (!dev->dma_mask || !dma_supported(dev, dma_mask))
+ return -EIO;
+
+ if (dma_mask == DMA_BIT_MASK(64)) {
+ if (cell_iommu_get_fixed_address(dev) == OF_BAD_ADDR)
+ dev_dbg(dev, "iommu: 64-bit OK, but bad addr\n");
+ else {
+ dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
+ set_dma_ops(dev, &dma_iommu_fixed_ops);
+ cell_dma_dev_setup(dev);
+ }
+ } else {
+ dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
+ set_dma_ops(dev, get_pci_dma_ops());
+ }
+
+ *dev->dma_mask = dma_mask;
+
+ return 0;
+}
+
+static void cell_dma_dev_setup_static(struct device *dev)
+{
+ struct dev_archdata *archdata = &dev->archdata;
+ u64 addr;
+
+ addr = cell_iommu_get_fixed_address(dev) + dma_iommu_fixed_base;
+ archdata->dma_data = (void *)addr;
+
+ dev_dbg(dev, "iommu: fixed addr = %lx\n", addr);
+}
+
+static void cell_iommu_setup_fixed_ptab(struct cbe_iommu *iommu,
+ struct device_node *np, unsigned long dbase, unsigned long dsize,
+ unsigned long fbase, unsigned long fsize)
+{
+ unsigned long base_pte, uaddr, *io_pte;
+ int i;
+
+ dma_iommu_fixed_base = fbase;
+
+ /* convert from bytes into page table indices */
+ dbase = dbase >> IOMMU_PAGE_SHIFT;
+ dsize = dsize >> IOMMU_PAGE_SHIFT;
+ fbase = fbase >> IOMMU_PAGE_SHIFT;
+ fsize = fsize >> IOMMU_PAGE_SHIFT;
+
+ pr_debug("iommu: mapping 0x%lx pages from 0x%lx\n", fsize, fbase);
+
+ io_pte = iommu->ptab;
+ base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW
+ | (cell_iommu_get_ioid(np) & IOPTE_IOID_Mask);
+
+ uaddr = 0;
+ for (i = fbase; i < fbase + fsize; i++, uaddr += IOMMU_PAGE_SIZE) {
+ /* Don't touch the dynamic region */
+ if (i >= dbase && i < (dbase + dsize)) {
+ pr_debug("iommu: static/dynamic overlap, skipping\n");
+ continue;
+ }
+ io_pte[i] = base_pte | (__pa(uaddr) & IOPTE_RPN_Mask);
+ }
+
+ mb();
+}
+
+static int __init cell_iommu_fixed_mapping_init(void)
+{
+ unsigned long dbase, dsize, fbase, fsize, hbase, hend;
+ struct cbe_iommu *iommu;
+ struct device_node *np;
+
+ /* The fixed mapping is only supported on axon machines */
+ np = of_find_node_by_name(NULL, "axon");
+ if (!np) {
+ pr_debug("iommu: fixed mapping disabled, no axons found\n");
+ return -1;
+ }
+
+ /* The default setup is to have the fixed mapping sit after the
+ * dynamic region, so find the top of the largest IOMMU window
+ * on any axon, then add the size of RAM and that's our max value.
+ * If that is > 32GB we have to do other shennanigans.
+ */
+ fbase = 0;
+ for_each_node_by_name(np, "axon") {
+ cell_iommu_get_window(np, &dbase, &dsize);
+ fbase = max(fbase, dbase + dsize);
+ }
+
+ fbase = _ALIGN_UP(fbase, 1 << IO_SEGMENT_SHIFT);
+ fsize = lmb_phys_mem_size();
+
+ if ((fbase + fsize) <= 0x800000000)
+ hbase = 0; /* use the device tree window */
+ else {
+ /* If we're over 32 GB we need to cheat. We can't map all of
+ * RAM with the fixed mapping, and also fit the dynamic
+ * region. So try to place the dynamic region where the hash
+ * table sits, drivers never need to DMA to it, we don't
+ * need a fixed mapping for that area.
+ */
+ if (!htab_address) {
+ pr_debug("iommu: htab is NULL, on LPAR? Huh?\n");
+ return -1;
+ }
+ hbase = __pa(htab_address);
+ hend = hbase + htab_size_bytes;
+
+ /* The window must start and end on a segment boundary */
+ if ((hbase != _ALIGN_UP(hbase, 1 << IO_SEGMENT_SHIFT)) ||
+ (hend != _ALIGN_UP(hend, 1 << IO_SEGMENT_SHIFT))) {
+ pr_debug("iommu: hash window not segment aligned\n");
+ return -1;
+ }
+
+ /* Check the hash window fits inside the real DMA window */
+ for_each_node_by_name(np, "axon") {
+ cell_iommu_get_window(np, &dbase, &dsize);
+
+ if (hbase < dbase || (hend > (dbase + dsize))) {
+ pr_debug("iommu: hash window doesn't fit in"
+ "real DMA window\n");
+ return -1;
+ }
+ }
+
+ fbase = 0;
+ }
+
+ /* Setup the dynamic regions */
+ for_each_node_by_name(np, "axon") {
+ iommu = cell_iommu_alloc(np);
+ BUG_ON(!iommu);
+
+ if (hbase == 0)
+ cell_iommu_get_window(np, &dbase, &dsize);
+ else {
+ dbase = hbase;
+ dsize = htab_size_bytes;
+ }
+
+ pr_debug("iommu: setting up %d, dynamic window %lx-%lx " \
+ "fixed window %lx-%lx\n", iommu->nid, dbase,
+ dbase + dsize, fbase, fbase + fsize);
+
+ cell_iommu_setup_page_tables(iommu, dbase, dsize, fbase, fsize);
+ cell_iommu_setup_fixed_ptab(iommu, np, dbase, dsize,
+ fbase, fsize);
+ cell_iommu_enable_hardware(iommu);
+ cell_iommu_setup_window(iommu, np, dbase, dsize, 0);
+ }
+
+ dma_iommu_fixed_ops = dma_direct_ops;
+ dma_iommu_fixed_ops.set_dma_mask = dma_set_mask_and_switch;
+
+ dma_iommu_ops.set_dma_mask = dma_set_mask_and_switch;
+ set_pci_dma_ops(&dma_iommu_ops);
+
+ printk(KERN_DEBUG "IOMMU fixed mapping established.\n");
+
+ return 0;
+}
+
+static int iommu_fixed_disabled;
+
+static int __init setup_iommu_fixed(char *str)
+{
+ if (strcmp(str, "off") == 0)
+ iommu_fixed_disabled = 1;
+
+ return 1;
+}
+__setup("iommu_fixed=", setup_iommu_fixed);
+
static int __init cell_iommu_init(void)
{
struct device_node *np;
@@ -771,6 +1033,9 @@ static int __init cell_iommu_init(void)
ppc_md.tce_build = tce_build_cell;
ppc_md.tce_free = tce_free_cell;
+ if (!iommu_fixed_disabled && cell_iommu_fixed_mapping_init() == 0)
+ goto bail;
+
/* Create an iommu for each /axon node. */
for_each_node_by_name(np, "axon") {
if (np->parent == NULL || np->parent->parent != NULL)
--
1.5.3.7.1.g4e596e
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Josh Boyer @ 2008-01-30 0:07 UTC (permalink / raw)
To: Grant Likely; +Cc: Stefan, Roese, Grant Erickson, linuxppc-embedded@ozlabs.org
In-Reply-To: <fa686aa40801291522y49c1b7e7n83c035f80fef1a12@mail.gmail.com>
On Tue, 29 Jan 2008 16:22:52 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 1/29/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > On Tue, 29 Jan 2008 14:49:59 -0800
> > Grant Erickson <gerickson@nuovations.com> wrote:
> >
> > > On 1/29/08 2:09 PM, Josh Boyer wrote:
> > > > On Tue, 29 Jan 2008 14:05:41 -0800
> > > > Grant Erickson <gerickson@nuovations.com> wrote:
> > > >
> > > >> Is there a patch pending to for 'arch/powerpc/configs/haleakala_defconfig'?
> > > >
> > > > Not to my knowledge.
> > > >
> > > >> I did not see one in either of:
> > > >>
> > > >> git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
> > > >> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> > > >>
> > > >> If no patch is pending, to whom do I submit such a patch? It'll simply be a
> > > >> near clone of 'kilauea_defconfig', save the "CONFIG_DEVICE_TREE" entry.
> > > >
> > > > Send one to me. CC Stefan Roese please.
> > > >
> > > > josh
> > >
> > > * Allow for 'make haleakala_defconfig' by providing a default configuration
> > > for the AMCC PowerPC 405EXr "Haleakala" board.
> > >
> >
> > As silly as it sounds, I need a Signed-off-by for this. Could you read
> > Documentation/SubmittingPatches section 12 and just reply to this with
> > a Signed-off-by line?
>
> Rather than adding more defconfigs, can we have a single defconfig for
> 440 and another one for 405? The configs directory is getting a bit
> silly.
You mean mulitplatform kernels? Or what do you mean?
josh
^ permalink raw reply
* Help: I will port amcc yucca board to denx kernel ARCH=powepc directory.How to config dts file?
From: jie han @ 2008-01-30 0:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
Hi all,
I want to port amcc yucca board denx linux kernel from ARCH=ppc to ARCH=powerpc. I used sequoia.dts for yucca baord demo device tree file.
I set uart0 as follow:
UART0: serial@f0000200 {
device_type = "serial";
compatible = "ns16550";
reg = <f0000200 8>;
virtual-reg = <f0000200>;
clock-frequency = <0>; /* Filled in by zImage */
current-speed = <1c200>;
interrupt-parent = <&UIC0>;
interrupts = <0 4>;
};
chosen {
linux,stdout-path = "/plb/opb/serial@f0000300";
bootargs = "console=ttyS0,115200";
};
the other parts of dts file is same as sequoia.dts.
When I run kernel.the tlb entry setup is wrong,the physical addres should be 4f0000200,but kernel calcuate is 1f0000200.I know yucca dts file isn't right.how can I fix it?Give me some advices,Thanks ahead,
Sincerely,
Jie
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
[-- Attachment #2: Type: text/html, Size: 2077 bytes --]
^ permalink raw reply
* Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Grant Likely @ 2008-01-30 0:12 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stefan, Roese, Grant Erickson, linuxppc-embedded@ozlabs.org
In-Reply-To: <20080129180712.1b37ba15@zod.rchland.ibm.com>
On 1/29/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Tue, 29 Jan 2008 16:22:52 -0700
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> > Rather than adding more defconfigs, can we have a single defconfig for
> > 440 and another one for 405? The configs directory is getting a bit
> > silly.
>
> You mean mulitplatform kernels? Or what do you mean?
Yes, multiplatform kernels.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* ppc64 vecemu compile failure
From: maximilian attems @ 2008-01-30 0:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Greg Kroah-Hartman
on latest git since driver subsys merge on powerpc64:
arch/powerpc/kernel/built-in.o: In function `fphalf':
vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys'
make[3]: *** [.tmp_vmlinux1] Error 1
^ permalink raw reply
* Re: [-mm PATCH] updates for hotplug memory remove
From: Badari Pulavarty @ 2008-01-30 0:31 UTC (permalink / raw)
To: Yasunori Goto; +Cc: linux-mm, Andrew Morton, linuxppc-dev
In-Reply-To: <20080129120318.5BDF.Y-GOTO@jp.fujitsu.com>
On Tue, 2008-01-29 at 14:18 +0900, Yasunori Goto wrote:
> Hello. Badari-san.
>
> Is your patch for notification the event of removing to firmware, right?
Correct.
>
> Have you ever tested hotadd(probe) of the removed memory?
Yes. I did. In my touch testing, I was able to remove memory and add
it back to the system without any issues. But again, I didn't force
the system to use that memory :(
> I'm afraid there are some differences of the status between pre hot-add
> section and the removed section by this patch. I think the mem_section of
> removed memory should be invalidated at least.
I think its a generic issue. Nothing specific for ppc64. Isn't it ?
Thanks,
Badari
>
> But anyway, this is a great first step for physical memory remove.
>
> Thanks.
>
>
> > On Mon, 2008-01-28 at 16:31 -0800, Badari Pulavarty wrote:
> >
> >
> > > 2) Can you replace the following patch with this ?
> > >
> > > add-remove_memory-for-ppc64-2.patch
> > >
> > > I found that, I do need arch-specific hooks to get the memory remove
> > > working on ppc64 LPAR. Earlier, I tried to make remove_memory() arch
> > > neutral, but we do need arch specific hooks.
> > >
> > > Thanks,
> > > Badari
> >
> > Andrew,
> >
> > Here is the patch which provides arch-specific code to complete memory
> > remove on ppc64 LPAR. So far, it works fine in my testing - but waiting
> > for ppc-experts for review and completeness.
> >
> > FYI.
> >
> > Thanks,
> > Badari
> >
> > For memory remove, we need to clean up htab mappings for the
> > section of the memory we are removing.
> >
> > This patch implements support for removing htab bolted mappings
> > for ppc64 lpar. Other sub-archs, may need to implement similar
> > functionality for the hotplug memory remove to work.
> >
> > Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> > ---
> > arch/powerpc/mm/hash_utils_64.c | 23 +++++++++++++++++++++++
> > arch/powerpc/mm/mem.c | 4 +++-
> > arch/powerpc/platforms/pseries/lpar.c | 15 +++++++++++++++
> > include/asm-powerpc/machdep.h | 2 ++
> > include/asm-powerpc/sparsemem.h | 1 +
> > 5 files changed, 44 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6.24-rc8/arch/powerpc/mm/hash_utils_64.c
> > ===================================================================
> > --- linux-2.6.24-rc8.orig/arch/powerpc/mm/hash_utils_64.c 2008-01-25 08:04:32.000000000 -0800
> > +++ linux-2.6.24-rc8/arch/powerpc/mm/hash_utils_64.c 2008-01-28 11:45:40.000000000 -0800
> > @@ -191,6 +191,24 @@ int htab_bolt_mapping(unsigned long vsta
> > return ret < 0 ? ret : 0;
> > }
> >
> > +static void htab_remove_mapping(unsigned long vstart, unsigned long vend,
> > + int psize, int ssize)
> > +{
> > + unsigned long vaddr;
> > + unsigned int step, shift;
> > +
> > + shift = mmu_psize_defs[psize].shift;
> > + step = 1 << shift;
> > +
> > + if (!ppc_md.hpte_removebolted) {
> > + printk("Sub-arch doesn't implement hpte_removebolted\n");
> > + return;
> > + }
> > +
> > + for (vaddr = vstart; vaddr < vend; vaddr += step)
> > + ppc_md.hpte_removebolted(vaddr, psize, ssize);
> > +}
> > +
> > static int __init htab_dt_scan_seg_sizes(unsigned long node,
> > const char *uname, int depth,
> > void *data)
> > @@ -436,6 +454,11 @@ void create_section_mapping(unsigned lon
> > _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX,
> > mmu_linear_psize, mmu_kernel_ssize));
> > }
> > +
> > +void remove_section_mapping(unsigned long start, unsigned long end)
> > +{
> > + htab_remove_mapping(start, end, mmu_linear_psize, mmu_kernel_ssize);
> > +}
> > #endif /* CONFIG_MEMORY_HOTPLUG */
> >
> > static inline void make_bl(unsigned int *insn_addr, void *func)
> > Index: linux-2.6.24-rc8/include/asm-powerpc/sparsemem.h
> > ===================================================================
> > --- linux-2.6.24-rc8.orig/include/asm-powerpc/sparsemem.h 2008-01-15 20:22:48.000000000 -0800
> > +++ linux-2.6.24-rc8/include/asm-powerpc/sparsemem.h 2008-01-25 08:18:11.000000000 -0800
> > @@ -20,6 +20,7 @@
> >
> > #ifdef CONFIG_MEMORY_HOTPLUG
> > extern void create_section_mapping(unsigned long start, unsigned long end);
> > +extern void remove_section_mapping(unsigned long start, unsigned long end);
> > #ifdef CONFIG_NUMA
> > extern int hot_add_scn_to_nid(unsigned long scn_addr);
> > #else
> > Index: linux-2.6.24-rc8/arch/powerpc/mm/mem.c
> > ===================================================================
> > --- linux-2.6.24-rc8.orig/arch/powerpc/mm/mem.c 2008-01-25 08:16:37.000000000 -0800
> > +++ linux-2.6.24-rc8/arch/powerpc/mm/mem.c 2008-01-25 08:20:33.000000000 -0800
> > @@ -156,7 +156,9 @@ int remove_memory(u64 start, u64 size)
> > ret = offline_pages(start_pfn, end_pfn, 120 * HZ);
> > if (ret)
> > goto out;
> > - /* Arch-specific calls go here - next patch */
> > +
> > + start = (unsigned long)__va(start);
> > + remove_section_mapping(start, start + size);
> > out:
> > return ret;
> > }
> > Index: linux-2.6.24-rc8/arch/powerpc/platforms/pseries/lpar.c
> > ===================================================================
> > --- linux-2.6.24-rc8.orig/arch/powerpc/platforms/pseries/lpar.c 2008-01-15 20:22:48.000000000 -0800
> > +++ linux-2.6.24-rc8/arch/powerpc/platforms/pseries/lpar.c 2008-01-28 14:10:58.000000000 -0800
> > @@ -520,6 +520,20 @@ static void pSeries_lpar_hpte_invalidate
> > BUG_ON(lpar_rc != H_SUCCESS);
> > }
> >
> > +static void pSeries_lpar_hpte_removebolted(unsigned long ea,
> > + int psize, int ssize)
> > +{
> > + unsigned long slot, vsid, va;
> > +
> > + vsid = get_kernel_vsid(ea, ssize);
> > + va = hpt_va(ea, vsid, ssize);
> > +
> > + slot = pSeries_lpar_hpte_find(va, psize, ssize);
> > + BUG_ON(slot == -1);
> > +
> > + pSeries_lpar_hpte_invalidate(slot, va, psize, ssize, 0);
> > +}
> > +
> > /* Flag bits for H_BULK_REMOVE */
> > #define HBR_REQUEST 0x4000000000000000UL
> > #define HBR_RESPONSE 0x8000000000000000UL
> > @@ -597,6 +611,7 @@ void __init hpte_init_lpar(void)
> > ppc_md.hpte_updateboltedpp = pSeries_lpar_hpte_updateboltedpp;
> > ppc_md.hpte_insert = pSeries_lpar_hpte_insert;
> > ppc_md.hpte_remove = pSeries_lpar_hpte_remove;
> > + ppc_md.hpte_removebolted = pSeries_lpar_hpte_removebolted;
> > ppc_md.flush_hash_range = pSeries_lpar_flush_hash_range;
> > ppc_md.hpte_clear_all = pSeries_lpar_hptab_clear;
> > }
> > Index: linux-2.6.24-rc8/include/asm-powerpc/machdep.h
> > ===================================================================
> > --- linux-2.6.24-rc8.orig/include/asm-powerpc/machdep.h 2008-01-25 08:04:41.000000000 -0800
> > +++ linux-2.6.24-rc8/include/asm-powerpc/machdep.h 2008-01-28 11:45:17.000000000 -0800
> > @@ -68,6 +68,8 @@ struct machdep_calls {
> > unsigned long vflags,
> > int psize, int ssize);
> > long (*hpte_remove)(unsigned long hpte_group);
> > + void (*hpte_removebolted)(unsigned long ea,
> > + int psize, int ssize);
> > void (*flush_hash_range)(unsigned long number, int local);
> >
> > /* special for kexec, to be called in real mode, linar mapping is
> >
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Josh Boyer @ 2008-01-30 0:40 UTC (permalink / raw)
To: Grant Likely; +Cc: Stefan, Roese, Grant Erickson, linuxppc-embedded@ozlabs.org
In-Reply-To: <fa686aa40801291612m9408b24idda1feac911f593b@mail.gmail.com>
On Tue, 29 Jan 2008 17:12:09 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 1/29/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > On Tue, 29 Jan 2008 16:22:52 -0700
> > "Grant Likely" <grant.likely@secretlab.ca> wrote:
> >
> > > Rather than adding more defconfigs, can we have a single defconfig for
> > > 440 and another one for 405? The configs directory is getting a bit
> > > silly.
> >
> > You mean mulitplatform kernels? Or what do you mean?
>
> Yes, multiplatform kernels.
Per IRC, I need patches or time ;)
josh
^ permalink raw reply
* Re: [PATCH 8/8] Cell IOMMU fixed mapping support
From: Arnd Bergmann @ 2008-01-30 0:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080129155048.GA19822@lixom.net>
On Tuesday 29 January 2008, Olof Johansson wrote:
>
> > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G
> > > is at 5G), to account for the MMIO range at 2-4G?
> >
> > I don't think so, ie. it works setup like that, but I'm not entirely
> > sure why. Presumably the 2-4GB for MMIO is only for cycles heading out
> > of the CPU.
>
> Ben denied that being so yesterday. :-)
>
> If that's the case, then you can stick the dynamic range there for >32GB
> configs, since it's still addressable with 32 bits.
>
For addresses going from the CPU to the bus, RAM is occupying everything
from zero to SIZE_OF_RAM, while PCI MMIO starts at LARGE_NUMBER+2GB.
As seen from the PCI bus, DMA addresses for RAM range from zero to 2GB,
while the MMIO space is between 2GB and 4GB. The 64 bit space for
the linear mapping is between EVEN_LARGER_NUMBER and
EVEN_LARGER_NUMBER+SIZE_OF_RAM.
The bridge chip remaps EVEN_LARGER_NUMBER to zero when going into the IOMMU,
so that the IOMMU can fit both SIZE_OF_RAM and the dynamic DMA window
into the 32GB bus address range.
I don't see how it should be possible here to reuse the 2-4GB range
for anything else.
Arnd <><
^ permalink raw reply
* Re: ppc64 vecemu compile failure
From: Olof Johansson @ 2008-01-30 0:56 UTC (permalink / raw)
To: maximilian attems; +Cc: linuxppc-dev, Greg Kroah-Hartman, Paul Mackerras
In-Reply-To: <20080130000337.GC25253@stro.at>
Hi,
On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote:
> on latest git since driver subsys merge on powerpc64:
>
> arch/powerpc/kernel/built-in.o: In function `fphalf':
> vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys'
> make[3]: *** [.tmp_vmlinux1] Error 1
It's a known problem, fixed by:
http://patchwork.ozlabs.org/linuxppc/patch?id=16491
-Olof
^ permalink raw reply
* Re: [PATCH 8/8] Cell IOMMU fixed mapping support
From: Olof Johansson @ 2008-01-30 0:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200801300154.02358.arnd@arndb.de>
On Wed, Jan 30, 2008 at 01:54:01AM +0100, Arnd Bergmann wrote:
> I don't see how it should be possible here to reuse the 2-4GB range
> for anything else.
Right, that was obvious after Ben's reply as well. Michael's description
made me think the linear mapping was at bus address 2G when it wasn't.
-Olof
^ permalink raw reply
* Re: [-mm PATCH] updates for hotplug memory remove
From: Yasunori Goto @ 2008-01-30 1:13 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linux-mm, Andrew Morton, linuxppc-dev
In-Reply-To: <1201653101.19684.6.camel@dyn9047017100.beaverton.ibm.com>
> > Have you ever tested hotadd(probe) of the removed memory?
>
> Yes. I did. In my touch testing, I was able to remove memory and add
> it back to the system without any issues.
Oh, really!?
> But again, I didn't force
> the system to use that memory :(
Ah..OK.
>
> > I'm afraid there are some differences of the status between pre hot-add
> > section and the removed section by this patch. I think the mem_section of
> > removed memory should be invalidated at least.
>
> I think its a generic issue. Nothing specific for ppc64. Isn't it ?
Right.
Currently, our machine doesn't have real physical remove feature yet.
(only add).
So, I think testing is not enough around physical removing.
Probably, your box will be first one which can remove physical memory
with Linux. It is good for testing.
If you notice anything, please let me know. :-)
Bye.
--
Yasunori Goto
^ permalink raw reply
* Re: ppc64 vecemu compile failure
From: Michael Ellerman @ 2008-01-30 1:39 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, Greg Kroah-Hartman, maximilian attems,
Paul Mackerras
In-Reply-To: <20080130005607.GA32622@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Tue, 2008-01-29 at 18:56 -0600, Olof Johansson wrote:
> Hi,
>
> On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote:
> > on latest git since driver subsys merge on powerpc64:
> >
> > arch/powerpc/kernel/built-in.o: In function `fphalf':
> > vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys'
> > make[3]: *** [.tmp_vmlinux1] Error 1
> It's a known problem, fixed by:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=16491
But begs the question, why is the linker lying to use about vecemu.c
using devices_subsys?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] hide kernel only code in asm-powerpc/elf.h
From: Michael Ellerman @ 2008-01-30 1:42 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080125180841.GA30091@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Fri, 2008-01-25 at 19:08 +0100, Olaf Hering wrote:
> stuff inside CONFIG_* should not be exported via make headers-install
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> ---
> include/asm-powerpc/elf.h | 2 ++
> 1 file changed, 2 insertions(+)
Thanks Olaf, I noticed that once but forgot to fix it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Help: I will port amcc yucca board to denx kernel ARCH=powepc directory.How to config dts file?
From: Josh Boyer @ 2008-01-30 1:49 UTC (permalink / raw)
To: jie han; +Cc: linuxppc-embedded
In-Reply-To: <593873.20606.qm@web15102.mail.cnb.yahoo.com>
On Tue, 29 Jan 2008 16:11:35 -0800 (PST)
jie han <jiehanca@yahoo.com.cn> wrote:
> Hi all,
> I want to port amcc yucca board denx linux kernel from ARCH=ppc to ARCH=powerpc. I used sequoia.dts for yucca baord demo device tree file.
I would start with the Katmai DTS instead. It's at least the same CPU
type.
josh
^ permalink raw reply
* Re: ppc64 vecemu compile failure
From: Olof Johansson @ 2008-01-30 1:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Greg Kroah-Hartman, maximilian attems,
Paul Mackerras
In-Reply-To: <1201657165.15799.0.camel@concordia>
On Wed, Jan 30, 2008 at 12:39:25PM +1100, Michael Ellerman wrote:
>
> On Tue, 2008-01-29 at 18:56 -0600, Olof Johansson wrote:
> > Hi,
> >
> > On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote:
> > > on latest git since driver subsys merge on powerpc64:
> > >
> > > arch/powerpc/kernel/built-in.o: In function `fphalf':
> > > vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys'
> > > make[3]: *** [.tmp_vmlinux1] Error 1
>
> > It's a known problem, fixed by:
> >
> > http://patchwork.ozlabs.org/linuxppc/patch?id=16491
>
> But begs the question, why is the linker lying to use about vecemu.c
> using devices_subsys?
Yes, that is a good question. fphalf isn't near it either.
-Olof
^ permalink raw reply
* Stephen Cheng is out of the office.
From: Stephen Cheng @ 2008-01-30 2:04 UTC (permalink / raw)
To: linuxppc-embedded
I will be out of the office starting 01/30/2008 and will not return until
02/13/2008.
This is the Chinese New Year Holiday. I will respond to your message when I
return.
^ permalink raw reply
* Re: ppc64 vecemu compile failure
From: Greg KH @ 2008-01-30 0:40 UTC (permalink / raw)
To: maximilian attems; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080130000337.GC25253@stro.at>
On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote:
> on latest git since driver subsys merge on powerpc64:
>
> arch/powerpc/kernel/built-in.o: In function `fphalf':
> vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys'
> make[3]: *** [.tmp_vmlinux1] Error 1
See the patches posted on lkml for this already.
thanks,
greg k-h
^ permalink raw reply
* Request help cross compiler problems
From: 军 @ 2008-01-30 2:37 UTC (permalink / raw)
To: xxx
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi, all :
I would like to migrate to linux SBC a15b (men mikro, mpc8245), I know that the most appropriate kernel 2.4.18 is, I need to know can be used in cross-compiler and version. Such as: eldk 3.0, it may be compiled 2.4.18? ?
Thank you!
gouxiaojun
2008.01.30
[-- Attachment #2: Type: text/html, Size: 1978 bytes --]
^ permalink raw reply
* which data structure keep IO information.
From: Barisa Kisku @ 2008-01-30 3:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
Hi,
I have to port one customised layer 2 protocol stack and read, write system
call to access devices in linux-2.4.
At the moment this is ported in UNIX SVR2/4 operating system.this protocol
uses some common data structure,
i.e "user" in unix srv2/4, which keeps information such as
u_error = return errorn code
u_base = base address for I/O
u_count = bytes remaining for I/O
u_arg = argument to current system call etc.
so i need to store these information in linux-2.4 implementation for
implementing read/write system calls.so what is/are
corresponding structure in linux-2.4.i went through task_struct, fs_struct,
files_struct etc., but couldn't relate it properly.
Please help me on this .
thanks and regards,
Barisa Kisku
[-- Attachment #2: Type: text/html, Size: 941 bytes --]
^ permalink raw reply
* 83xx HDLC Driver Dev - Multiple PHYs?
From: Russell McGuire @ 2008-01-30 5:10 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <D71D9F25-4724-487E-AD07-E848B4608B97@freescale.com>
All,
I have gotten my HDLC driver up to the point where it can register itself
with the Linux kernel. However now I am faced with a dilemma and style
question, that is probably best answered by you driver developers that have
more experience.
I am putting support for multiple PHY's into the HDLC driver, but after
converting it to use the of_device tree, and inserting a UCC@5000 for a
single UCC HDLC driver, it occurred to me that if I insert more devices
(UCC@6000, UCC@7000, UCC@8000) that the driver will attempt to load multiple
times.
So here is the question.
Solution 1:
Should I develop the system to have a single ucc@xxxx entry in the
platform.dts file and have a field(s) like phy-count=<4>, to support
multiple devices? And have each instance of the module contain private data
for one UCC, interrupt handling, etc...
OR
Solution 2:
Is there a way to have a module know if it has already been loaded, so it
doesn't insert multiple times and then play the rest like Solution 3?
OR
Solution 3:
Have phy-count=4; defined in the driver header, or a module parameter, and
have a single module instance of the driver itself responsible for creating
a single private data structure and setting up multiple UCC's and PHY's?
This also feeds into a question on SET_NETDEV_DEV. How does it react to
multiple net devices attached to a single base driver?
-Russ
> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: Tuesday, January 29, 2008 2:33 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: SET_NETDEV_DEV -> 83xx HDLC Driver??
>
>
> On Jan 25, 2008, at 20:43, Russell McGuire wrote:
>
> > All,
> >
> > I am partly done porting a combination of the 83xx ATM driver and
> > dscc4 HDLC
> > driver into a 83xx HDLC driver.
> >
> > However, encounter a call I don't truly understand.
> >
> > SET_NETDEV_DEV(dev, pointer_to_some_handle);
> >
> > I can see plenty of examples of this registering some kind of PCI
> > device
> > handle, however in this case I am not using a PCI device. So what
> > should the
> > pointer be? Or can this call be ignored, and if so what are the
> > consequences?
> >
> > I see the some of the Freescale Ethernet devices don't use this call.
> >
> > Anyway, can somebody shed some light on if I am going to need this,
> > or a way
> > to get it to work, without creating a PCI device?
>
>
> Look at gianfar.c (which uses a platform_device) or ucc_geth (which
> uses an of_device). Which freescale devices don't use that call?
> We'll fix them.
>
> Andy
^ permalink raw reply
* Re: [PATCH powerpc] Fake NUMA emulation for PowerPC (Take 3)
From: Balbir Singh @ 2008-01-29 13:50 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1201611898.26410.7.camel@concordia>
* Michael Ellerman <michael@ellerman.id.au> [2008-01-30 00:04:58]:
> Why do you check !p after assigning to nid? I assume it's because we
> might have reached the end of the command line, ie. p == NULL, but we're
> still adding memory to the last node? If so it's a it's a little subtle
> and deserves a comment I think.
>
The reason that we check for !p after assigning node id is that, in
case we create fake NUMA nodes, we want nid to be the fake numa node
id and not the real node id or in the non NUMA case, node id 0.
The if (!p) checks to see if we do have more arguments to parse.
> Otherwise this looks pretty good.
>
Thanks!
> cheers
>
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH 0/6] PS3: gelic: gelic updates for 2.6.25
From: Masakazu Mokuno @ 2008-01-30 5:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Geert Uytterhoeven, netdev, Linux/PPC Development
In-Reply-To: <20071213181146.BF69.MOKUNO@sm.sony.co.jp>
Hi Jeff,
The patch set I posted on Dec 13 2007 (except v2 of #6) have been
reviewed on the ML and seems to have no more outstanding
comments/requests.
http://marc.info/?l=linux-netdev&m=119754603814092
Is it OK to apply for 2.6.25? If OK, I'll ask Paul to merge this set
into the powerpc tree with my wireless patch because the dependent patch
set will go into the tree.
best regards
--
Masakazu MOKUNO
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-01-30 6:16 UTC (permalink / raw)
To: linuxppc-dev, benh; +Cc: netdev
In-Reply-To: <20080116090110.1b7b2f00@zod.rchland.ibm.com>
On Wednesday 16 January 2008, Josh Boyer wrote:
> On Wed, 16 Jan 2008 20:53:59 +1100
>
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > > With the removal the the "rgmii-interface" device_type property from
> > > the dts files, the newemac driver needs an update to only rely on
> > > compatible property.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > I need to test if it works on CAB, can't change the DT on those. I'll
> > let you know tomorrow.
>
> This should be fine on CAB. The rgmii node has:
>
> compatible = "ibm,rgmii-axon", "ibm,rgmii"
>
> so the match should still catch on the latter.
How about this patch? Ben, if you think this is ok then we should make sure
that it goes in in this merge-window, since the other dts patch relies on it.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Stefan Roese @ 2008-01-30 6:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stefan, Grant Erickson, linuxppc-embedded@ozlabs.org
In-Reply-To: <20080129184016.423aed6a@zod.rchland.ibm.com>
On Wednesday 30 January 2008, Josh Boyer wrote:
> On Tue, 29 Jan 2008 17:12:09 -0700
>
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
> > On 1/29/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > > On Tue, 29 Jan 2008 16:22:52 -0700
> > >
> > > "Grant Likely" <grant.likely@secretlab.ca> wrote:
> > > > Rather than adding more defconfigs, can we have a single defconfig
> > > > for 440 and another one for 405? The configs directory is getting a
> > > > bit silly.
> > >
> > > You mean mulitplatform kernels? Or what do you mean?
> >
> > Yes, multiplatform kernels.
>
> Per IRC, I need patches or time ;)
As long as multiplatform is not available for 4xx I'm ok with this patch:
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [NET]: Remove PowerPC code from fec.c
From: Jeff Garzik @ 2008-01-30 8:41 UTC (permalink / raw)
To: Jochen Friedrich
Cc: linux-m68k, Kernel, Linux, linuxppc-dev list, Geert Uytterhoeven,
netdev@vger.kernel.org, Scott Wood
In-Reply-To: <4799F349.9090102@scram.de>
Jochen Friedrich wrote:
> fec.c is only used on M68k Coldfire CPUs. Remove leftover
> PowerPC code from this driver.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> drivers/net/fec.c | 136 +---------------------------------------------------
> 1 files changed, 3 insertions(+), 133 deletions(-)
Seems OK to me, but I feel I don't have enough knowledge to ACK or NAK.
Please pass through an arch tree, thanks.
Jeff
^ 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