* Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Josh Boyer @ 2008-01-29 22:59 UTC (permalink / raw)
To: Grant Erickson; +Cc: Roese, Stefan, linuxppc-embedded@ozlabs.org
In-Reply-To: <C3C4ED97.D197%gerickson@nuovations.com>
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?
josh
^ permalink raw reply
* RE: SET_NETDEV_DEV -> 83xx HDLC Driver??
From: Russell McGuire @ 2008-01-29 23:04 UTC (permalink / raw)
To: 'Andy Fleming'; +Cc: linuxppc-embedded
In-Reply-To: <D71D9F25-4724-487E-AD07-E848B4608B97@freescale.com>
Andy,
/drivers/net/fec_8xx
Doesn't use the call, though I imagine it is legacy or only for older
boards.
Thanks for pointing me at the newer stuff, guess I had a brain cramp and
didn't think to look there. Also makes much more sense now that the
pdev->dev is not a PCI device but a Platform device.
One question, since you've probably got more experience with this than I do.
The gianfar, and ucc_geth drivers are not modules. Is there a problem with
using these driver _probe_ functions in a module style driver? OR should I
just change my driver over to be a platform style?
As far as I can tell the HDLC driver I am trying to create for the 83xx is
going to be somewhat similar to the Ethernet driver. Only I don't want it
loaded as part of the kernel.
-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] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Grant Erickson @ 2008-01-29 23:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stefan Roese, linuxppc-embedded@ozlabs.org
In-Reply-To: <20080129165941.1681842f@zod.rchland.ibm.com>
On 1/29/08 2:59 PM, Josh Boyer wrote:
>> * 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?
* Allow for 'make haleakala_defconfig' by providing a default configuration
for the AMCC PowerPC 405EXr "Haleakala" board.
Signed-off-by: Grant Erickson <gerickson@nuovations.com>
---
^ permalink raw reply
* Re: SET_NETDEV_DEV -> 83xx HDLC Driver??
From: Scott Wood @ 2008-01-29 23:16 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <002301c862cb$54f73770$6405a8c0@absolut>
Russell McGuire wrote:
> Andy,
>
> /drivers/net/fec_8xx
>
> Doesn't use the call, though I imagine it is legacy or only for older
> boards.
I don't think it's used on anything, actually. drivers/net/fs_enet is
the driver for 8xx fec.
-Scott
^ permalink raw reply
* Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Grant Likely @ 2008-01-29 23:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stefan, Roese, Grant Erickson, linuxppc-embedded@ozlabs.org
In-Reply-To: <20080129165941.1681842f@zod.rchland.ibm.com>
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.
I've consolidated the defconfigs for 5200 and Kumar is doing the same
for 8xxx. All the pasemi platforms have used a single defconfig for a
while now.
Cheers,
g.
>
> josh
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 8/8] Cell IOMMU fixed mapping support
From: Michael Ellerman @ 2008-01-29 23:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: cbe-oss-dev, linuxppc-dev
In-Reply-To: <20080129213646.GA28997@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]
On Tue, 2008-01-29 at 15:36 -0600, Olof Johansson wrote:
> On Wed, Jan 30, 2008 at 08:18:15AM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Wed, 2008-01-30 at 02:13 +1100, Michael Ellerman wrote:
> > > On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote:
> > > > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote:
> > > >
> > > > > 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.
> > > >
> > > > 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.
> >
> > No no no... it's because on the PCI segment, it's all offset up
> > remember ?
> >
> > Basically, the PCI host bridge on these has 2 interesting windows for
> > us:
> >
> > 0....2G -> This goes up to memory @0 (via a couple of
> > layers)
> >
> > 0x80*....0xF* -> This goes untranslated to the PLB5 which
> > drops the top bits and does some other
> > manipulations, which allows to access, among
> > others the full 32GB of the cell inbound
> > range.
> >
> > The MMIO region of 2...4G is on the PCI (outbound from the Cell is yet
> > another range of addresses with different constraints but that ends up
> > generating cycles between 2 and 4G on the PCI segment).
> >
> > If we had set the direct mapped region so that it uses 2G...N on PCI, we
> > would indeed be toast. But instead, the addresses for direct DMA that we
> > hand out to devices are in the 0x80* region and go hit the cell
> > directly, they never match MMIO.
>
> Yeah, ok. That makes more sense. Thanks for the clarification.
Right, that's the firmware offset I mentioned in the changelog - 2am is
not a good time to think about these things.
> Michael, btw, I wonder if it would make sense to duplicate the patch
> description at the top of the file as well, since it'll be lost in the
> change log for people who don't go back and read history, and having
> the intentions documented in the file could be a good idea.
Yeah that probably makes sense. I've got most of the fixed mapping code
in a block, so I'll put a comment above that section. New patch coming.
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
* [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
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