* 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: [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
* 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: 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
* [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 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
* 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: 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 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: 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: 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
* [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
From: Grant Erickson @ 2008-01-29 22:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stefan Roese, linuxppc-embedded@ozlabs.org
In-Reply-To: <20080129160924.6186b6a1@zod.rchland.ibm.com>
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.
diff -auN paulus.git/arch/powerpc/configs/haleakala_defconfig
linux-2.6.24-git6/arch/powerpc/configs/haleakala_defconfig
--- paulus.git/arch/powerpc/configs/haleakala_defconfig 1969-12-31
16:00:00.000000000 -0800
+++ linux-2.6.24-git6/arch/powerpc/configs/haleakala_defconfig 2008-01-29
14:24:42.000000000 -0800
@@ -0,0 +1,754 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.24-rc4
+# Thu Dec 6 16:48:20 2007
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+# CONFIG_6xx is not set
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+CONFIG_40x=y
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_4xx=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_IRQ_PER_CPU=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+# CONFIG_PPC_UDBG_16550 is not set
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+# CONFIG_DEFAULT_UIMAGE is not set
+CONFIG_PPC_DCR_NATIVE=y
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_PPC_DCR=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CGROUPS is not set
+# CONFIG_FAIR_GROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+# CONFIG_RELAY is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+
+#
+# Platform support
+#
+# CONFIG_PPC_MPC52xx is not set
+# CONFIG_PPC_MPC5200 is not set
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+# CONFIG_PQ2ADS is not set
+CONFIG_KILAUEA=y
+# CONFIG_WALNUT is not set
+# CONFIG_XILINX_VIRTEX_GENERIC_BOARD is not set
+# CONFIG_MPIC is not set
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PPC_RTAS is not set
+# CONFIG_MMIO_NVRAM is not set
+# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
+# CONFIG_PPC_INDIRECT_IO is not set
+# CONFIG_GENERIC_IOMAP is not set
+# CONFIG_CPU_FREQ is not set
+# CONFIG_CPM2 is not set
+# CONFIG_FSL_ULI1575 is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_MATH_EMULATION is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+# CONFIG_RESOURCES_64BIT is not set
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+CONFIG_SUSPEND_UP_POSSIBLE=y
+CONFIG_HIBERNATION_UP_POSSIBLE=y
+CONFIG_SECCOMP=y
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE="haleakala.dts"
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+# CONFIG_PCI is not set
+# CONFIG_PCI_DOMAINS is not set
+# CONFIG_PCI_SYSCALL is not set
+# CONFIG_ARCH_SUPPORTS_MSI is not set
+# CONFIG_PCCARD is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0xc0000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x00400000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+
+#
+# Wireless
+#
+# CONFIG_CFG80211 is not set
+# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
+# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+CONFIG_FW_LOADER=y
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+# CONFIG_SYS_HYPERVISOR is not set
+CONFIG_CONNECTOR=y
+CONFIG_PROC_EVENTS=y
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=m
+CONFIG_MTD_BLOCK=m
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
+CONFIG_OF_DEVICE=y
+# CONFIG_PARPORT is not set
+CONFIG_BLK_DEV=y
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=35000
+CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+# CONFIG_XILINX_SYSACE is not set
+# CONFIG_MISC_DEVICES is not set
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_DMA is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+# CONFIG_MD is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NETDEVICES_MULTIQUEUE is not set
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+# CONFIG_NET_ETHERNET is not set
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_10000 is not set
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 is not set
+# CONFIG_WAN is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+# CONFIG_ISDN is not set
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_R3964 is not set
+# CONFIG_RAW_DRIVER is not set
+# CONFIG_TCG_TPM is not set
+# CONFIG_I2C is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
+# CONFIG_HWMON is not set
+# CONFIG_WATCHDOG is not set
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+# CONFIG_DAB is not set
+
+#
+# Graphics support
+#
+# CONFIG_VGASTATE is not set
+# CONFIG_VIDEO_OUTPUT_CONTROL is not set
+# CONFIG_FB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_MMC is not set
+# CONFIG_NEW_LEDS is not set
+# CONFIG_EDAC is not set
+# CONFIG_RTC_CLASS is not set
+
+#
+# Userspace I/O
+#
+# CONFIG_UIO is not set
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4DEV_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
+# CONFIG_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+# CONFIG_NLS is not set
+# CONFIG_DLM is not set
+# CONFIG_UCC_SLOW is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_CRC7 is not set
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+# CONFIG_INSTRUMENTATION is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_FS is not set
+# CONFIG_HEADERS_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DETECT_SOFTLOCKUP=y
+CONFIG_SCHED_DEBUG=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
+# CONFIG_SLUB_DEBUG_ON is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_DEBUG_KOBJECT is not set
+CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_LIST is not set
+# CONFIG_DEBUG_SG is not set
+CONFIG_FORCED_INLINING=y
+# CONFIG_BOOT_PRINTK_DELAY is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_SAMPLES is not set
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+# CONFIG_DEBUGGER is not set
+# CONFIG_BDI_SWITCH is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_BLKCIPHER=y
+CONFIG_CRYPTO_MANAGER=y
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+CONFIG_CRYPTO_MD5=y
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=y
+# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_XTS is not set
+# CONFIG_CRYPTO_CRYPTD is not set
+CONFIG_CRYPTO_DES=y
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_SEED is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_TEST is not set
+# CONFIG_CRYPTO_AUTHENC is not set
+CONFIG_CRYPTO_HW=y
+# CONFIG_PPC_CLOCK is not set
^ permalink raw reply
* Re: SET_NETDEV_DEV -> 83xx HDLC Driver??
From: Andy Fleming @ 2008-01-29 22:32 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000601c85fc5$41e48330$6405a8c0@absolut>
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: Haleakala Defconfg
From: Josh Boyer @ 2008-01-29 22:09 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <C3C4E335.D193%gerickson@nuovations.com>
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
^ permalink raw reply
* Haleakala Defconfg
From: Grant Erickson @ 2008-01-29 22:05 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Is there a patch pending to for 'arch/powerpc/configs/haleakala_defconfig'?
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.
Regards,
Grant Erickson
^ permalink raw reply
* Re: [PATCH 8/8] Cell IOMMU fixed mapping support
From: Olof Johansson @ 2008-01-29 21:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1201641495.6815.207.camel@pasglop>
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.
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.
-Olof
^ permalink raw reply
* Re: [PATCH 8/8] Cell IOMMU fixed mapping support
From: Benjamin Herrenschmidt @ 2008-01-29 21:18 UTC (permalink / raw)
To: michael; +Cc: Olof Johansson, linuxppc-dev, cbe-oss-dev
In-Reply-To: <1201619625.10012.19.camel@concordia>
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.
Ben.
^ permalink raw reply
* Re: PATCH[1/1] 8xx: Add clock-frequency to .dts brg entries
From: Bryan O'Donoghue @ 2008-01-29 20:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080129162611.GA4599@ld0162-tx32.am.freescale.net>
On Tue, 2008-01-29 at 10:26 -0600, Scott Wood wrote:
> On Mon, Jan 28, 2008 at 11:55:20PM +0000, Bryan O'Donoghue wrote:
> > You mean that arch/powerpc/boot/mpc8xx.c mpc8xx_set_clocks is supposed
> > to be adding this field ?
>
> Yes. Or u-boot, if you're not using the bootwrapper/cuImage.
Indeed - I have some patches to send to the u-boot mailing list to cover
manipulation of the "fsl,cpm-brg" "clock-frequency" entry.
The previously sent patch will allow Linux to print stuff out the UART
will the default brgclk - from a uImage and is the field that a future
u-boot patchset would want to manipulate in order to tell Linux about
the brgclk it should have.
I should be a bit clearer about that...
>
> > I see arch/powerpc/boot/wrapper.a has a reference to the function but -
> > and this time I've checked all documentation - there's no mention of how
> > to use this library at all... it _looks_ to me like this isn't being
> > linked in any way.
> >
> > It for sure is nowhere in the uImage - and I've taken the preferred
> > route of making a uImage with .dtb - genreated from adder875-uboot.dts
>
> In that case, u-boot needs to add that property.
See above.
> > dtc -O -o adder875-uboot.dtb arch/powerpc/boot/dts/adder875-uboot.dtb
>
> You'll want to use the -p option to add some extra space for u-boot to
> use.
Interesting - the u-boot end of this patch is something I'm still
messing about with ... but, the addition of the default brgclk to the
Linux dts is a useful addition - and AFAICT will be needed to allow a
bootloader to manipulate the dts so that Linux will get the right
brgclk.
> > cpm_uart depends on "fsl,cpm-brg" and a field called "clock-frequency"
> >
> > as I understand it that's
> >
> > fsl,cpm-brg
> > |_clock-frequency
> >
> > whereas mpc8xx_set_clocks seems to add
> >
> > /soc/cpm/brg
> > |_clock-frequency
>
> The fsl,cpm-brg refers to the compatible property, not the node name.
Indeed and the get_brgclk does a find_compatible() lookup of some
sort... so I think that means this is the right field to add to allow a
bootloader to manipulate the brgclk ... it's what the other stuff in
u-boot for the mpc8xxx stuff does, so it follows to do the same thing
for 8xx too.
> > mpc866ads.dts - also has a "fsl,cpm-brg" => clock-frequency entry in
> >
> > linux/arch/powerpc/boot/dts/mpc866ads.dts - and to me this looks like
> > the correct approach for get_brgfreq to function properly...
>
> And it's zero, meaning that you still need u-boot or the bootwrapper to
> fill in the correct value.
Indeed - I'm hoping I won't have too much trouble getting those patches
applied...
^ permalink raw reply
* Re: Patches for Peak CAN driver for MPC5200B?
From: Wolfgang Grandegger @ 2008-01-29 19:50 UTC (permalink / raw)
To: Mattias Boström; +Cc: linuxppc-embedded
In-Reply-To: <10d674cb0801290848p8cd6d1xdf03e793e6de58a1@mail.gmail.com>
Hi Mattias,
Mattias Boström wrote:
> Hi,
>
> We are using peak-linux-driver-3.17 with patches from DENX (mpc5200)
> and Freescale (mpc5200-platform_driver) on a MPC5200B. We have
> problems with rmmod, resulting in kernel panic. We also have a problem
> with not detecting BusOff. Does anyone know of additional patches that
> solve these problems?
> If we solve it ourselfs, would this be a good place to post patches?
This driver is not maintained any more. Are you aware of the Socket-CAN
project at BerliOS:
http://developer.berlios.de/projects/socketcan/
http://svn.berlios.de/wsvn/socketcan/trunk/README?op=file&rev=0&sc=0
It also supports the MSCAN driver and the CAN core will be merged into
2.6.25:
https://lists.berlios.de/pipermail/socketcan-core/2007-November/000795.html
Nevertheless, if you report me your problems, I might be able to help
you. And patches are always welcome.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 4/4] 82xx: MGCOGE support
From: Scott Wood @ 2008-01-29 19:31 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <20080129192454.GC4051@loki.buserror.net>
On Tue, Jan 29, 2008 at 01:24:54PM -0600, Scott Wood wrote:
> On Tue, Jan 29, 2008 at 11:22:55AM +0100, Heiko Schocher wrote:
> > + *pram_base = res.start;
>
> First of all, use out_be32() rather than direct dereferencing.
Err, I meant out_be16() of course. :-P
-Scott
^ permalink raw reply
* Re: [PATCH 3/4] 82xx: MGCOGE support
From: Jon Loeliger @ 2008-01-29 19:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Heiko Schocher
In-Reply-To: <20080129192033.GB4051@loki.buserror.net>
Scott Wood wrote:
>> + // Temporary -- will go away once kernel uses ranges for get_immrbase().
>> + reg = <0xf0000000 0x00053000>;
>
> The patch to use ranges for get_immrbase() just went in, so we can drop this
> now.
Most excellent.
Time for YARDS -- Yet Another Rounds of DTS Scrubbing.
jdl
^ permalink raw reply
* Re: [PATCH 4/4] 82xx: MGCOGE support
From: Scott Wood @ 2008-01-29 19:24 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <479EFE7F.4000104@denx.de>
On Tue, Jan 29, 2008 at 11:22:55AM +0100, Heiko Schocher wrote:
> To get the serial console on the SMC2 working, the
> following patch is needed:
>
> Fixing serial console on a SMC on MPC82xx based
> board and using CONFIG_PPC_CPM_NEW_BINDING
No, what's needed is for the device tree to be correct (see my comments on
that patch).
> + u16 __iomem *pram_base;
> + struct resource res;
> +
> pinfo->flags |= FLAG_SMC;
> pinfo->smcp = mem;
> pinfo->smcup = pram;
> +
> + if (of_address_to_resource(np, 1, &res)) {
> + ret = -ENOMEM;
> + goto out_pram;
> + }
> + pram_base = of_iomap(np, 2);
> + if (!pram_base) {
> + ret = -ENOMEM;
> + goto out_pram;
> + }
> + *pram_base = res.start;
First of all, use out_be32() rather than direct dereferencing.
Secondly, is it possible for things to get messed up if the SMC registers
were set somewhere else by the bootloader, and that area was previously
allocated by Linux for some other purpose, and the SMC updated the parameter
RAM and corrupted that other purpose? Especially if we have early debug
enabled, and thus don't reset the CPM on boot (or worse, are actively using
it prior to register relocation).
-Scott
^ permalink raw reply
* Re: [PATCH 3/4] 82xx: MGCOGE support
From: Scott Wood @ 2008-01-29 19:20 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <479EFE71.5090201@denx.de>
On Tue, Jan 29, 2008 at 11:22:41AM +0100, Heiko Schocher wrote:
> + model = "MGCOGE";
> + compatible = "fsl,mgcoge";
keymile,mgcoge
> + PowerPC,8247@0 {
[snip]
> + compatible = "fsl,mpc8248-localbus",
All of these 8248s should be 8247.
> + // Temporary -- will go away once kernel uses ranges for get_immrbase().
> + reg = <0xf0000000 0x00053000>;
The patch to use ranges for get_immrbase() just went in, so we can drop this
now.
> + data@0 {
> + compatible = "fsl,cpm-muram-data";
> + reg = <0 0x1100 0x1140
> + 0xec0 0x9800 0x800>;
This doesn't look right. You're excluding 0x40 bytes at 0x1100, which is
where planetcore puts SMC1. However, you're using SMC2 -- and I'm guessing
aren't using planetcore, since this isn't an embedded planet board.
If you're using u-boot, this should be:
reg = <0x80 0x1f80 0x9800 0x800>;
> + /* Monitor port/SMC2 */
> + smc2: serial@11a90 {
> + device_type = "serial";
> + compatible = "fsl,mpc8248-smc-uart",
> + "fsl,cpm2-smc-uart";
> + reg = <0x11a90 0x20 0x1100 0x40 0x88fc 4>;
If you're using u-boot, this should be <0x11a90 0x20 0x40 0x40>.
> + current-speed = <0x1c200>;
This should be decimal.
-Scott
^ permalink raw reply
* Re: Patches for Peak CAN driver for MPC5200B?
From: Grant Likely @ 2008-01-29 19:17 UTC (permalink / raw)
To: Mattias Boström; +Cc: linuxppc-embedded
In-Reply-To: <10d674cb0801290848p8cd6d1xdf03e793e6de58a1@mail.gmail.com>
On 1/29/08, Mattias Bostr=F6m <mattias.bostroem@gmail.com> wrote:
> Hi,
>
> We are using peak-linux-driver-3.17 with patches from DENX (mpc5200)
> and Freescale (mpc5200-platform_driver) on a MPC5200B. We have
> problems with rmmod, resulting in kernel panic. We also have a problem
> with not detecting BusOff. Does anyone know of additional patches that
> solve these problems?
> If we solve it ourselfs, would this be a good place to post patches?
Direct your patches to linuxppc-dev@ozlabs.org. That list gets more reader=
ship.
cc me on any patches that you send to make sure that I see them.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/3] 82xx: MGCOGE support
From: Scott Wood @ 2008-01-29 19:09 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <479EFDE8.1030204@denx.de>
On Tue, Jan 29, 2008 at 11:20:24AM +0100, Heiko Schocher wrote:
> the following 4 patches adding support for the MPC8247
> based board MGCOGE from keymile.
Please use descriptive subject lines, rather than the same one for each
patch in the series.
Also, the first three patches could be combined into one.
-Scott
^ 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