Re: [PATCH] add Phytec pcm030 board support
On Tue, 6 May 2008 07:51:55 +0200 Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > > OLPC? check? > > No check. The kernel hardly uses the device tree at all, there. oh, OK. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpNcFqKyidUf.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fwd: linux2.6 does not boot from XUP
Hi ,boys . I am in the XiDian universtiy of china . I am doing the things ike yours.You can try set ttyUL0,if you use the Uartlite. If it don't work , may be gcc 4.1.0 miscompile the kernel 2.6 , I am using the gcc3.4.4. Good luck 张轶 wrote: > > -- Forwarded message -- > From: 张轶 <[EMAIL PROTECTED]> > Date: 2008/5/5 > Subject: linux2.6 does not boot from XUP > To: [EMAIL PROTECTED] > > > Hi,Grant > > I hope I could get some advices from you about how to fix the error of > porting linux2.6 to Xilinx XUPV2P. > > The kernel I am using is 2.6.24,gcc 4.1.0,glibc 2.3.6,and the board Xilinx > XUPV2P > > It compiles successfully with some warnings like below: > MODPOST vmlinux.o > WARNING: vmlinux.o(.text+0x223c): Section mismatch: reference to > .init.text:early_init (between 'start_here' and 'initial_mmu') > WARNING: vmlinux.o(.text+0x2254): Section mismatch: reference to > .init.text:machine_init (between 'start_here' and 'initial_mmu') > WARNING: vmlinux.o(.text+0x2258): Section mismatch: reference to > .init.text:MMU_init (between 'start_here' and 'initial_mmu') > WARNING: vmlinux.o(.text+0x22b2): Section mismatch: reference to > .init.text:start_kernel (between 'start_here' and 'initial_mmu') > WARNING: vmlinux.o(.text+0x22b6): Section mismatch: reference to > .init.text:start_kernel (between 'start_here' and 'initial_mmu') >LD vmlinux > > The system is created as ACE file and booted from CF Card > > After uncompressing the kernel,the system hangs.The information is like > below: > > loaded at: 0040 0056619C > board data at: 007C > relocated to: 00404068 004040E4 > zimage at: 00404E51 00563BF4 > avail ram: 00567000 7C9E2370 > > Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw > Uncompressing Linux...done. > Now booting the kernel > I wonder if it is the upper WARNINGs that causes the hang of the system, > and > how can I fix it. > > Thanks in advance, any advice would be helpful > > Best Regards > > Yi > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- View this message in context: http://www.nabble.com/Fwd%3A-linux2.6-does-not-boot-from-XUP-tp17074762p17077099.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
Original-Nachricht > Datum: Tue, 06 May 2008 09:44:18 +1000 > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > An: Gerhard Pircher <[EMAIL PROTECTED]> > CC: Kumar Gala <[EMAIL PROTECTED]>, [EMAIL PROTECTED], linuxppc-dev@ozlabs.org > Betreff: Re: [PATCH] Sam440ep support > > On Mon, 2008-05-05 at 21:50 +0200, Gerhard Pircher wrote: > > This is a (bad) hack that I also use on the AmigaOne to get the ALSA > > sound drivers working with DMA, because ALSA doesn't work with > > dma-noncoherent.c. The problem is the "nopage" mechanism, which fails > > with non coherent DMA allocations due to their own virtual address > > space (correct me, if I'm wrong). > > > > See this thread for more info: > > http://readlist.com/lists/vger.kernel.org/linux-kernel/45/226541.html > > > > This is a general problem that affects all powerpc boards that use > > dma-noncoherent.c with ALSA PCI drivers. > > The link above doesn't provide any useful information on the problem and > it contains itself a non working link... Sorry, I didn't check the embedded link. This one should work: http://www.uwsg.iu.edu/hypermail/linux/kernel/0406.2/0801.html IIRC the problem is the mmaping of non coherent DMA allocations, as you already know. The link above points to a very old (from 2004) and quite long thread where the correct DMA API for mmaping DMA allocations was discussed. > Can somebody explains exactly what's going on ? That shouldn't be hard > to fix. I can't believe the problem has been around for 2 years and > nobody actually bothered fixing it properly. Takashi Iwai posted a preliminary patch a long time ago. I tested it on my machine and it failed with non coherent scatter-gather DMA allocations (I guess almost all ALSA PCI drivers use SG DMA?). Thanks! Gerhard -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Phytec pcm030 board support
On Mon, May 05, 2008 at 01:22:40PM -0400, Jon Smirl wrote:
> On 5/5/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On Mon, May 5, 2008 at 11:01 AM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > Did this get fixed somehow? I used to need this to boot a pcm030.
> >
> >
> > I'm sorry; I'm at a lost as to context. Are you asking for this patch
> > to be applied? Or are you asking if this has been addressed in
> > another way?
>
> Sascha said the pcm030 was working with the simple dts. I always
> needed that patch to get a pcm030 to boot. Sasha's company wrote the
> patch. I'm just wondering how it got handled, do we still need the
> patch or did he come up with some other solution.
Yes, it is working with the simple dts except for the flash support. For
this we need the Flash description in the oftree.
> > >
> > > diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
> > > index 272872d..c982adc 100644
> > > --- a/fs/jffs2/scan.c
> > > +++ b/fs/jffs2/scan.c
> > > @@ -16,6 +16,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include "nodelist.h"
> > > #include "summary.h"
> > > #include "debug.h"
> > > @@ -505,7 +506,7 @@ static int jffs2_scan_eraseblock (struct
> > > jffs2_sb_info *c, struct jffs2_eraseblo
> > > sumptr = kmalloc(sumlen,
> > GFP_KERNEL);
> > > if (!sumptr)
> > > return -ENOMEM;
> > > - memcpy(sumptr + sumlen -
> > > buf_len, buf + buf_size - buf_len, buf_len);
> > > + memcpy_fromio(sumptr + sumlen
> > > - buf_len, buf + buf_size - buf_len, buf_len);
> > > }
> > > if (buf_len < sumlen) {
> > > /* Need to read more so that
> > > the entire summary node is present */
> > > @@ -1035,7 +1036,7 @@ static int jffs2_scan_dirent_node(struct
> > > jffs2_sb_info *c, struct jffs2_eraseblo
> > > if (!fd) {
> > > return -ENOMEM;
> > > }
> > > - memcpy(&fd->name, rd->name, checkedlen);
> > > + memcpy_fromio(&fd->name, rd->name, checkedlen);
This patch is needed because memcpy uses unaligned accesses whereas
memcpy_fromio only uses aligned accesses on the io side. See this
thread: http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022544.html
--
Pengutronix e.K. - Linux Solutions for Science and Industry
---
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if there is i8259 PIC
On Mon, May 05, 2008 at 10:55:38PM +0400, Anton Vorontsov wrote:
> Sometimes (particularly on MPC8610HPCD) we want IRQ-less CMOS RTC for
> the boards without (or disabled) i8259 PICs.
>
> We lookup the device tree for "chrp,iic" compatible devices, and if not
> found we do not assign RTC IRQ.
I suspect this will break on machines which have an RTC and the
interrupt line is not connected.
These are PreP machines like MVME2[467]xxx (I have a bunch of them,
stilll running 2.2 kernels but on a private network).
Interrupt 8 is connected, but not to the RTC...
I have no problems with the patch going in for now, it will have
to be revisited whenever (if ever) support for these machines is added
to the kernel (what is really needed to support these machines is a
residual data->device tree converter).
Gabriel
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/rtc_cmos_setup.c | 21 +++--
> 1 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c
> b/arch/powerpc/sysdev/rtc_cmos_setup.c
> index c09ddc0..e5d0bcb 100644
> --- a/arch/powerpc/sysdev/rtc_cmos_setup.c
> +++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
> @@ -21,6 +21,7 @@ static int __init add_rtc(void)
> struct device_node *np;
> struct platform_device *pd;
> struct resource res[2];
> + unsigned int num_res = 1;
> int ret;
>
> memset(&res, 0, sizeof(res));
> @@ -41,14 +42,22 @@ static int __init add_rtc(void)
> if (res[0].start != RTC_PORT(0))
> return -EINVAL;
>
> - /* Use a fixed interrupt value of 8 since on PPC if we are using this
> - * its off an i8259 which we ensure has interrupt numbers 0..15. */
> - res[1].start = 8;
> - res[1].end = 8;
> - res[1].flags = IORESOURCE_IRQ;
> + np = of_find_compatible_node(NULL, NULL, "chrp,iic");
> + if (np) {
> + of_node_put(np);
> + /*
> + * Use a fixed interrupt value of 8 since on PPC if we are
> + * using this its off an i8259 which we ensure has interrupt
> + * numbers 0..15.
> + */
> + res[1].start = 8;
> + res[1].end = 8;
> + res[1].flags = IORESOURCE_IRQ;
> + num_res++;
> + }
>
> pd = platform_device_register_simple("rtc_cmos", -1,
> - &res[0], 2);
> + &res[0], num_res);
>
> if (IS_ERR(pd))
> return PTR_ERR(pd);
> --
> 1.5.5.1
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/5] PS3: Update ps3_defconfig
Hi Geoff, On Monday 05 May 2008 21:00:47 you wrote: > Marvin wrote: > > what about adding these defaults: > > - CONFIG_SCHED_SMT > > - CONFIG_HUGETLBFS (needed by ibm cell sdk) I'm using these for years now ;-) > > not sure about: > > - CONFIG_SPU_FS_64K_LS I also have this option enabled. I think you can forget about it, as it seems to improve performance only in some corner cases. I'm not an expert, so maybe asking at cbe-oss-dev would be a better place. Thanks Marvin p.s. I installed fc9 last week and Xorg crashes when PCI is not enabled. just in case someone has the same problem. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if there is i8259 PIC
Original-Nachricht > Datum: Mon, 5 May 2008 22:55:38 +0400 > Von: Anton Vorontsov <[EMAIL PROTECTED]> > An: Kumar Gala <[EMAIL PROTECTED]> > CC: linuxppc-dev@ozlabs.org > Betreff: [PATCH 1/2] [POWERPC] rtc_cmos_setup: assign interrupts only if > there is i8259 PIC > Sometimes (particularly on MPC8610HPCD) we want IRQ-less CMOS RTC for > the boards without (or disabled) i8259 PICs. > > We lookup the device tree for "chrp,iic" compatible devices, and if not > found we do not assign RTC IRQ. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > --- > arch/powerpc/sysdev/rtc_cmos_setup.c | 21 +++-- > 1 files changed, 15 insertions(+), 6 deletions(-) > > diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c > b/arch/powerpc/sysdev/rtc_cmos_setup.c > index c09ddc0..e5d0bcb 100644 > --- a/arch/powerpc/sysdev/rtc_cmos_setup.c > +++ b/arch/powerpc/sysdev/rtc_cmos_setup.c > @@ -21,6 +21,7 @@ static int __init add_rtc(void) > struct device_node *np; > struct platform_device *pd; > struct resource res[2]; > + unsigned int num_res = 1; > int ret; > > memset(&res, 0, sizeof(res)); > @@ -41,14 +42,22 @@ static int __init add_rtc(void) > if (res[0].start != RTC_PORT(0)) > return -EINVAL; > > - /* Use a fixed interrupt value of 8 since on PPC if we are using this > - * its off an i8259 which we ensure has interrupt numbers 0..15. */ > - res[1].start = 8; > - res[1].end = 8; > - res[1].flags = IORESOURCE_IRQ; > + np = of_find_compatible_node(NULL, NULL, "chrp,iic"); Could you add a check for "pnpPNP,000" (PNP ID for i8259), as not all platforms use the CHRP names? Gerhard -- 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro. Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
On Tue, 2008-05-06 at 09:51 +0200, Gerhard Pircher wrote: > Takashi Iwai posted a preliminary patch a long time ago. I tested it > on my > machine and it failed with non coherent scatter-gather DMA allocations > (I guess almost all ALSA PCI drivers use SG DMA?). How does Alsa allocate such SG ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 4/4] booting-without-of for Freescale MSI
> > > +- compatible : should be "fsl,MPIC-MSI" for 85xx/86xx cpu, > > + and "fsl,IPIC-MSI" for 83xx cpu. > > Please use a more specific name, "fsl,8599-msi" or similar? > Thanks for your input. I think the name "fsl,MPIC-MSI" and "fsl,IPIC-MSI" is somethind specific. Actually, from the hardware point, MSI is just part of MPIC of IPIC for Freescale CPU. the name "fsl,MPIC-MSI" can describe the MSI is based on the MPIC controller. > > +- interrupts : should contain the msi interrupts cascade to the > > host > > + interrupt controller. > > You should describe that it is one "interrupts" entry per 32 > MSIs; also, it would be nice to say they need "0" as the sense. > > > +- interrupt-parent: should be "&mpic" for 85xx/86xx cpu and > > "&ipic" > > + for 83xx cpu. > > &Xpic are labels, so something local to specific DTS files; > instead, say that the interrupts are routed to the MPIC/IPIC > (it doesn't have to be via "interrupt-parent", either). > Thank you, I'll rewrite these description. > Segher > > p.s. On a meta-note, please put the binding doc first in the > series, it makes things easier to review in-order. Ok, I'll put it first next time. Jason ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/4 V3] MSI support on 83xx/85xx/86xx board
Hi Micheal,
Thank you for your comments.
I'll send the new version according to feedback.
Jason
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 05, 2008 7:24 PM
> To: Jin Zhengxiong
> Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/4 V3] MSI support on 83xx/85xx/86xx board
>
> On Mon, 2008-05-05 at 15:47 +0800, Jason Jin wrote:
> > This MSI driver can be used on 83xx/85xx/86xx board.
> > In this driver, virtual interrupt host and chip were setup.
> There are
> > 256 MSI interrupts in this host, Every 32 MSI interrupts
> cascaded to
> > one IPIC/MPIC interrupt.
> > The chip was treated as edge sensitive and some necessary functions
> > were setup for this chip.
> >
> > Before using the MSI interrupt, PCI/PCIE device need to ask
> for a MSI
> > interrupt in the 256 MSI interrupts. A 256bit bitmap show which MSI
> > interrupt was used, reserve bit in the bitmap can be used
> to force the
> > device use some designate MSI interrupt in the 256 MSI interrupts.
> > Sometimes this is useful for testing the all the MSI
> interrupts. The
> > msi-available-ranges property in the dts file was used for this
> > purpose.
> >
> > Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
>
>
> Hi Jason,
>
> Just a couple of comments below:
>
> > diff --git a/arch/powerpc/sysdev/fsl_msi.c
> > b/arch/powerpc/sysdev/fsl_msi.c new file mode 100644 index
> > 000..c53f716
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/fsl_msi.c
> > @@ -0,0 +1,442 @@
> > +/*
> > + * Copyright (C) 2007-2008 Freescale Semiconductor, Inc.
> All rights reserved.
> > + *
> > + * Author: Tony Li <[EMAIL PROTECTED]>
> > + *Jason Jin <[EMAIL PROTECTED]>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; version 2 of the
> > + * License.
> > + *
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "fsl_msi.h"
> > +
> > +struct fsl_msi_feature {
> > + u32 fsl_pic_ip;
> > + u32 msiir_offset;
> > +};
> > +
> > +/* A bit ugly, can we get this from the pci_dev somehow? */
>
> This comment is old (from my code) and should go.
>
> > +static struct fsl_msi *fsl_msi;
> > +
> > +static inline u32 fsl_msi_read(u32 __iomem *base, unsigned
> int reg) {
> > + return in_be32(base + (reg >> 2));
> > +}
> > +
> > +static inline void fsl_msi_write(u32 __iomem *base,
> > + unsigned int reg, u32 value)
> > +{
> > + out_be32(base + (reg >> 2), value);
> > +}
> > +
> > +/*
> > + * We do not need this actually. The MSIR register has
> been read once
> > + * in the cascade interrupt. So, this MSI interrupt has
> been acked */
> > +static void fsl_msi_end_irq(unsigned int virq) { }
> > +
> > +static struct irq_chip fsl_msi_chip = {
> > + .mask = mask_msi_irq,
> > + .unmask = unmask_msi_irq,
> > + .ack= fsl_msi_end_irq,
> > + .typename = " FSL-MSI ",
> > +};
> > +
> > +static int fsl_msi_host_match(struct irq_host *h, struct
> device_node
> > +*node) {
> > + /* Exact match, unless node is NULL */
> > + return h->of_node == NULL || h->of_node == node; }
>
> Are you sure you want this as your match routine? It looks
> wrong to me.
> You won't ever create a fsl_msi in your probe routine unless
> you have a device node, so AFAICT the of_node == NULL is only
> ever going to match some _other_ irqhost.
>
>
> > diff --git a/arch/powerpc/sysdev/fsl_msi.h
> > b/arch/powerpc/sysdev/fsl_msi.h new file mode 100644 index
> > 000..0449c96
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/fsl_msi.h
> > @@ -0,0 +1,31 @@
> > +#ifndef _POWERPC_SYSDEV_FSL_MSI_H
> > +#define _POWERPC_SYSDEV_FSL_MSI_H
>
>
> This should have a copyright header.
>
> > +#define NR_MSI_REG 8
> > +#define IRQS_PER_MSI_REG 32
> > +#define NR_MSI_IRQS(NR_MSI_REG * IRQS_PER_MSI_REG)
> > +
> > +#define FSL_PIC_IP_MASK0x000F
> > +#define FSL_PIC_IP_MPIC0x0001
> > +#define FSL_PIC_IP_IPIC0x0002
> > +
> > +struct fsl_msi {
> > + /* Device node of the MSI interrupt*/
> > + struct device_node *of_node;
> > +
> > + struct irq_host *irqhost;
> > +
> > + unsigned long cascade_irq;
> > +
> > + u32 msi_addr_lo;
> > + u32 msi_addr_hi;
> > + void __iomem *msi_regs;
> > + u32 feature;
> > +
> > + unsigned long *fsl_msi_bitmap;
> > + spinlock_t bitmap_lock;
> > + const char *name;
>
> I don't see where this is used?
>
>
> 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
>
___
Re: [PATCH] Sam440ep support
Original-Nachricht > Datum: Tue, 06 May 2008 18:48:39 +1000 > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > An: Gerhard Pircher <[EMAIL PROTECTED]> > CC: linuxppc-dev@ozlabs.org, Takashi Iwai <[EMAIL PROTECTED]>, [EMAIL > PROTECTED], [EMAIL PROTECTED] > Betreff: Re: [PATCH] Sam440ep support > > On Tue, 2008-05-06 at 09:51 +0200, Gerhard Pircher wrote: > > Takashi Iwai posted a preliminary patch a long time ago. I tested it > > on my machine and it failed with non coherent scatter-gather DMA > > allocations (I guess almost all ALSA PCI drivers use SG DMA?). > > How does Alsa allocate such SG ? I can't answer this question. *ducked* :-) Takashi? FYI: I posted the results of the test with Takashi's dma_mmap_coherent patch here: http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html On the other side it looks like this problem does not only affect ALSA. As far as I can tell also some V4L(2) drivers have a problem with mmaping non coherent DMA allocations, but I'm not sure (it's a long time since I did some tests with video cards on my AmigaOne). Naturally I can do some tests, if you or Takashi come up with a new patch. Thanks! Gerhard -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
On Tue, 2008-05-06 at 11:16 +0200, Gerhard Pircher wrote: > I can't answer this question. *ducked* :-) Takashi? > > FYI: I posted the results of the test with Takashi's dma_mmap_coherent > patch here: > http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html > > On the other side it looks like this problem does not only affect > ALSA. > As far as I can tell also some V4L(2) drivers have a problem with > mmaping > non coherent DMA allocations, but I'm not sure (it's a long time since > I > did some tests with video cards on my AmigaOne). > > Naturally I can do some tests, if you or Takashi come up with a new > patch. Time that we sort that stuff out once for all.. sg allocations are usually lists of page, so virt_to_page shouldn't be a problem in the first place, though we still need some way to get the right prot attributes. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for Analogue & Micro ASP837E board
On Tue, 6 May 2008 16:11:10 +1000
Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> Hi Bryan,
>
> On Tue, 6 May 2008 03:28:13 +0100 Bryan O'Donoghue <[EMAIL PROTECTED]>
> wrote:
> >
> > +static void __init asp834x_init_IRQ(void)
> > +{
> > + struct device_node *np;
> > +
> > + np = of_find_node_by_type(NULL, "ipic");
> > + if (!np)
> > + return;
> > +
> > + ipic_init(np, 0);
>
> You need an "of_node_put(np)" here to drop the reference gained in
> "of_find_node_by_type".
>
> > +static struct of_device_id asp8347_ids[] = {
>
> Please make this __initdata.
>
Hey Stephen.
Thanks for spotting that. Will do.
Cheers,
Bryan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] Xorg crash when PCI not enabled (was [patch 5/5] PS3: Update ps3_defconfig)
Hi On Tue, 2008-05-06 at 10:14 +0200, Marvin wrote: > p.s. I installed fc9 last week and Xorg crashes when PCI is not > enabled. just > in case someone has the same problem. The Ubuntu PS3 team is also working on an a couple of bugs relating to lack of PCI info. I don't know if these are the same issues you're facing. We're tracking them here at [0] and [2]. We had an initial crash was simple to fix [1]. Now we need to get X to automatically load the fbdev driver instead of vesa [2]. Cheers Dan [0] https://bugs.launchpad.net/ubuntu-ps3-port/+bug/217647 [1] http://launchpadlibrarian.net/13569440/closedir.patch [2] https://bugs.launchpad.net/ubuntu-ps3-port/+bug/219424 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/5] PS3: Update ps3_defconfig
On Tue, 2008-05-06 at 10:14 +0200, Marvin wrote: > Hi Geoff, > > On Monday 05 May 2008 21:00:47 you wrote: > > Marvin wrote: > > > what about adding these defaults: > > > - CONFIG_SCHED_SMT > > > - CONFIG_HUGETLBFS (needed by ibm cell sdk) > > I'm using these for years now ;-) > > > > not sure about: > > > - CONFIG_SPU_FS_64K_LS > > I also have this option enabled. I think you can forget about it, as it seems > to improve performance only in some corner cases. I'm not an expert, so maybe > asking at cbe-oss-dev would be a better place. Assuming it works on PS3 (the HV lets us use 64k pages I take it?) I think it should be enabled. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.
Current standard practice is not to represent the DCR bus as node with subnodes for the DCR-controlled devices. That's because the DCR bus tends to run in addition to other on-chip busses, and some things have to go on another on-chip bus to make sense, but still have DCR control registers (for example the internal bus bridges on 4xx). Yeah. Arguably for DCR-only devices we should instead have a node representing the DCR bus and just put the devices under it with the DCR number encoded in reg in the normal way. Right. But then its inconsistent with the devices that need the other DCR representation. OTOH, it _is_ consistent with all other (non-DCR) devices that way. What you could do right now is to give such DCR-only devices both normal "reg" etc., and the "dcr-reg" etc. properties, containing both the same info. If you do that, your device tree will be correct (because you got all the standard stuff right), and the kernel will like it as well (because it looks for the "dcr-reg" stuff). Then maybe later, if/when the kernel supports the standard addressing for DCR as well, you could drop the "dcr-reg" things from your DTS. Or you could just keep it. David, will this work, do you think? Segher and I did toss around some ideas for generalizing the DCR representation to a way of representing that any node has some presence on a bus other than its "primary" parent (e.g. other-bus-reg = <&dcr-bus 0x0d0 0x010 &strange-i2c-control-bus 0xabc>). Then DCR-only devices would use normal "reg", devices that sit on another bus would sit on that bus and use this representation to show their DCR control registers. Maybe one day. One day perhaps, yes :-) It sounds cleaner to split such a prop into separate props per bus. Maybe I said the opposite before, heh :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ALSA vs. non coherent DMA
Hi Ben, thanks for signaling this long-standing issue again. At Tue, 06 May 2008 10:08:28 +1000, Benjamin Herrenschmidt wrote: > > Hi Takashi ! > > I'm bringing up an old thread as I'm just discovering that the problem > still hasn't been fixed. > > There seem to be a few issues with ALSA current usage of mmap vs. non > cache coherent architecture, such as embedded PowerPC's. Yep. And on MIPS, obviously. > I can see at least two with a quick look to pcm-native.c, one I don't > understand and one I think I do: > > - The control/status mapping. Can you elaborate a bit on what this is > actually doing and why it shouldn't be done on "non coherent" > architectures ? This is a mmap of the data record to be shared in realtime with apps. The app updates its data pointer (appl_ptr) on the mmapped buffer while the driver updates the data (e.g. DMA position, called hwptr) on the fly on the mmapped record. Due to its real-time nature, it has to be coherent -- at least, it was a problem on ARM. > Currently this -is- done on all powerpc's, whether they > are coherent or not and I want to understand what the underlying issue > is. It's actually buggy. Should check more precisely. > - The mmap of DMA pages. Here, the problem appears two fold: > > * Use of virt_to_page() on virtual addresses returned by > dma_alloc_coherent(). > > * No using the appropriate page protection for a DMA coherent mapping > to userspace. > > It seems like you have solved that in part with implementing a generic > dma_mmap_coherent() in the past that for some reason you never merged > upstream (I can track that to about 2 years ago). Is there a reason ? IIRC, dma_mmap_coherent() cannot be implemented properly on some architectures. This is no big problem for ALSA as long as it returns an error or make it out via ifdef. But, the fact that this API cannot be done for all archs discourage arch maintainers, and the idea faded out again. > I think we need to at least apply a band-aid today as it's becoming a > nasty issue for several non-coherent powerpc platforms. It could be in > the form of implementing dma_mmap_coherent() and changing Alsa to use it > with the appropriate ifdef, or just adding an ifdef CONFIG_PPC with the > right code in there for now until a better solution is found. Agreed. > It should be trivial though. Getting the PFN from the DMA address is > easy if we have the dma handle and the virtual address, though that -is- > definitely platform specific. I can implement a function for that if you > need. That'll be great. dma_mmap_coherent() and friends would be then really helpful to solve this issue. > As for the pgprot, we can come up with something like > pgprot_mmap_dma(). Either that or I can fold it all in a powerpc wide > implementation of a dma_mmap_coherent() like we envisioned initially. In principle, pgprot_*() isn't actually needed in the driver side at all. We use pgprot_noncached() in one part, and it's for hacky way to mmap the ioremapped pages. It's not available on all architectures, and I'm not sure whether it works on all PPC models although it's enabled right now: in include/sound/pcm.h, /* mmap for io-memory area */ #if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) #define SNDRV_PCM_INFO_MMAP_IOMEM SNDRV_PCM_INFO_MMAP int snd_pcm_lib_mmap_iomem(struct snd_pcm_substream *substream, struct vm_area_struct *area); #else #define SNDRV_PCM_INFO_MMAP_IOMEM 0 #define snd_pcm_lib_mmap_iomem NULL #endif Highly likely we need to fix this, too. In the easiest way, disable this except for X86... > Let me know what approach is preferred here and I'll come up with > patches ASAP. As far as I'm concerned, this is a bug and thus must be > fixed now for .26 and possibly backported to stable even if we can come > up with a non invasive solution). I'm annoyed because it represents a > trivial amount of code, this problem should have been fixed a long time > ago. As a pragmatic solution, as you mentioned in the above, we can disable or change the problematic code with ifdefs. At best, use dma_mmap_coherent() if it's available. If not, and if the arch is known to have not-simply-mappable DMA pages (like MIPS), we can simply disable the mmap feature. Once after we have dma_mmap_*() generally, we can clean up codes. thanks, Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
At Tue, 06 May 2008 20:12:27 +1000, Benjamin Herrenschmidt wrote: > > > On Tue, 2008-05-06 at 11:16 +0200, Gerhard Pircher wrote: > > I can't answer this question. *ducked* :-) Takashi? > > > > FYI: I posted the results of the test with Takashi's dma_mmap_coherent > > patch here: > > http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html > > > > On the other side it looks like this problem does not only affect > > ALSA. > > As far as I can tell also some V4L(2) drivers have a problem with > > mmaping > > non coherent DMA allocations, but I'm not sure (it's a long time since > > I > > did some tests with video cards on my AmigaOne). > > > > Naturally I can do some tests, if you or Takashi come up with a new > > patch. > > Time that we sort that stuff out once for all.. > > sg allocations are usually lists of page, so virt_to_page shouldn't be a > problem in the first place, though we still need some way to get the > right prot attributes. The problem is that ALSA SG buffer is composed from pages allocated via dma_alloc_coherent(), and the pages are retrieved via virt_to_page for DMA pages, as found in sound/core/sgbuf.c. I didn't care about SG-buffer cases in my initial patch, and it's a bit messy. The current code requires page lists becasue it calls vmap() to get a virtually linear buffer. Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
On Tue, 2008-05-06 at 13:14 +0200, Takashi Iwai wrote: > > sg allocations are usually lists of page, so virt_to_page shouldn't > be a > > problem in the first place, though we still need some way to get the > > right prot attributes. > > The problem is that ALSA SG buffer is composed from pages allocated > via dma_alloc_coherent(), and the pages are retrieved via virt_to_page > for DMA pages, as found in sound/core/sgbuf.c. > > I didn't care about SG-buffer cases in my initial patch, and it's a > bit messy. The current code requires page lists becasue it calls > vmap() to get a virtually linear buffer. Hrm... the problem is that you aren't supposed to make up sglists with the result of dma_alloc_coherent... It might be a limitation of our core DMA API, but that's we have to deal with today.. If you're going to make up sglists and call vmap, you should allocate pages with normal GFP. If that is a problem vs. DMA'bility of those pages, then ... we have a problem :-) I don't think we can easily update the DMA API at this stage. What we could do is provide a way to retrieve the struct page array from the result of dma_alloc_coherent... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
> Hrm... the problem is that you aren't supposed to make up sglists with > the result of dma_alloc_coherent... It might be a limitation of our core > DMA API, but that's we have to deal with today.. > > If you're going to make up sglists and call vmap, you should allocate > pages with normal GFP. If that is a problem vs. DMA'bility of those > pages, then ... we have a problem :-) > > I don't think we can easily update the DMA API at this stage. What we > could do is provide a way to retrieve the struct page array from the > result of dma_alloc_coherent... Another option is to allocate the pages with gfp, and then dma_map_sg the result... However, if we do that, we do need to add a way to vmap with the right protection in order to get a coherent (ie. non cacheable) mapping. I'm not even sure all archs can do that Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] booting-without-of for Freescale MSI
+- compatible : should be "fsl,MPIC-MSI" for 85xx/86xx cpu, + and "fsl,IPIC-MSI" for 83xx cpu. Please use a more specific name, "fsl,8599-msi" or similar? Thanks for your input. I think the name "fsl,MPIC-MSI" and "fsl,IPIC-MSI" is somethind specific. This is the third MSI-on-MPIC I've seen, and I doubt it will be the last. It is likely FSL will make some different one in the future, as well. Please don't use generic names for specific devices. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
At Tue, 06 May 2008 21:25:53 +1000, Benjamin Herrenschmidt wrote: > > > On Tue, 2008-05-06 at 13:14 +0200, Takashi Iwai wrote: > > > sg allocations are usually lists of page, so virt_to_page shouldn't > > be a > > > problem in the first place, though we still need some way to get the > > > right prot attributes. > > > > The problem is that ALSA SG buffer is composed from pages allocated > > via dma_alloc_coherent(), and the pages are retrieved via virt_to_page > > for DMA pages, as found in sound/core/sgbuf.c. > > > > I didn't care about SG-buffer cases in my initial patch, and it's a > > bit messy. The current code requires page lists becasue it calls > > vmap() to get a virtually linear buffer. > > Hrm... the problem is that you aren't supposed to make up sglists with > the result of dma_alloc_coherent... It might be a limitation of our core > DMA API, but that's we have to deal with today.. > > If you're going to make up sglists and call vmap, you should allocate > pages with normal GFP. If that is a problem vs. DMA'bility of those > pages, then ... we have a problem :-) > > I don't think we can easily update the DMA API at this stage. What we > could do is provide a way to retrieve the struct page array from the > result of dma_alloc_coherent... In most cases, it can be obtained via pfn_to_page(), I suppose. But, it's definitely arch-specific thingy, and a generic solution would be really appreciated. Alternatively, we can change the ALSA PCM core code that accesses the virtual linear buffer and handles SG-buffers as they are. Maybe it'll give a bit more useful clean-up in the whole memory-management codes in ALSA in the end. Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
On Tue, 2008-05-06 at 13:31 +0200, Takashi Iwai wrote: > > I don't think we can easily update the DMA API at this stage. What > we > > could do is provide a way to retrieve the struct page array from the > > result of dma_alloc_coherent... > > In most cases, it can be obtained via pfn_to_page(), I suppose. But, > it's definitely arch-specific thingy, and a generic solution would be > really appreciated. You can't get a pfn out of the result of dma_alloc_coherent on non-coherent powerpc at least. It's a virtual mapping created from the underlying pages set to be non-cacheable. virt_to_* will do no good. > Alternatively, we can change the ALSA PCM core code that accesses the > virtual linear buffer and handles SG-buffers as they are. Maybe it'll > give a bit more useful clean-up in the whole memory-management codes > in ALSA in the end. I need to get my head around what the exact usage in Alsa is, and it's a bit too late for me to thing right now :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add Phytec pcm030 board support
On 5/6/08, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> On Mon, May 05, 2008 at 01:22:40PM -0400, Jon Smirl wrote:
> > On 5/5/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On Mon, May 5, 2008 at 11:01 AM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > > Did this get fixed somehow? I used to need this to boot a pcm030.
> > >
> > >
> > > I'm sorry; I'm at a lost as to context. Are you asking for this patch
> > > to be applied? Or are you asking if this has been addressed in
> > > another way?
> >
> > Sascha said the pcm030 was working with the simple dts. I always
> > needed that patch to get a pcm030 to boot. Sasha's company wrote the
> > patch. I'm just wondering how it got handled, do we still need the
> > patch or did he come up with some other solution.
>
>
> Yes, it is working with the simple dts except for the flash support. For
> this we need the Flash description in the oftree.
>
>
> > > >
> > > > diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
> > > > index 272872d..c982adc 100644
> > > > --- a/fs/jffs2/scan.c
> > > > +++ b/fs/jffs2/scan.c
> > > > @@ -16,6 +16,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include "nodelist.h"
> > > > #include "summary.h"
> > > > #include "debug.h"
> > > > @@ -505,7 +506,7 @@ static int jffs2_scan_eraseblock (struct
> > > > jffs2_sb_info *c, struct jffs2_eraseblo
> > > > sumptr = kmalloc(sumlen,
> GFP_KERNEL);
> > > > if (!sumptr)
> > > > return -ENOMEM;
> > > > - memcpy(sumptr + sumlen -
> > > > buf_len, buf + buf_size - buf_len, buf_len);
> > > > + memcpy_fromio(sumptr + sumlen
> > > > - buf_len, buf + buf_size - buf_len, buf_len);
> > > > }
> > > > if (buf_len < sumlen) {
> > > > /* Need to read more so that
> > > > the entire summary node is present */
> > > > @@ -1035,7 +1036,7 @@ static int jffs2_scan_dirent_node(struct
> > > > jffs2_sb_info *c, struct jffs2_eraseblo
> > > > if (!fd) {
> > > > return -ENOMEM;
> > > > }
> > > > - memcpy(&fd->name, rd->name, checkedlen);
> > > > + memcpy_fromio(&fd->name, rd->name, checkedlen);
>
>
> This patch is needed because memcpy uses unaligned accesses whereas
> memcpy_fromio only uses aligned accesses on the io side. See this
> thread: http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022544.html
Can you submit it for inclusion? That's the last thing needed to boot
a pcm030 on a standard kernel, right?
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for Analogue & Micro ASP837E board
@@ -0,0 +1,247 @@
+/*
+ * Analogue & Micro ASP8347 Device Tree Source
+ *
+ * Copyright 2008 Codehermit
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "ASP8347E";
+ compatible = "ASP8347E";
"analogue-and-micro, ASP8347E";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0x0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>;
+ i-cache-size = <32768>;
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>; // from bootloader
+ clock-frequency = <0>;// from bootloader
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x800>; // 128MB at 0
is memory really fixed on this board or does the bootloader set this
if, dynamic make it <0 0>
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8347e-localbus",
+"fsl,pq2pro-localbus",
+"simple-bus";
+ reg = <0xff005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ ranges = <
+ 0 0 0xf000 0x0200
+ >;
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x0200>;
+ bank-width = <2>;
+ device-width = <2>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <0x0 0xff00 0xff10>;
this is wrong, size should be like 0x10
+ reg = <0xff00 0x0200>;
+ bus-frequency = <0>;
+
+ [EMAIL PROTECTED] {
+ device_type = "watchdog";
+ compatible = "mpc83xx_wdt";
+ reg = <0x200 0x100>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <14 0x8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+
+ [EMAIL PROTECTED] {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <15 0x8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ cell-index = <0>;
+ compatible = "fsl,spi";
+ reg = <0x7000 0x1000>;
+ interrupts = <16 0x8>;
+ interrupt-parent = <&ipic>;
+ mode = "cpu";
+ };
+
+ /* phy type (ULPI or SERIAL) are only types supported for MPH */
+ /* port = 0 or 1 */
+ [EMAIL PROTECTED] {
+ compatible = "fsl-usb2-mph";
+ reg = <0x22000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&ipic>;
+ interrupts = <39 0x8>;
+ phy_type = "ulpi";
+ port1;
+ };
+ /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
+ [EMAIL PROTECTED] {
+ compatible = "fsl-usb2-dr";
+ reg = <0x23000 0x1000>;
+ #add
Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
Hi Jochen,
I just had a debug session with a MPC8260 + eeprom and got some
questions:
> This driver uses the port of 2.4 code from Vitaly Bordug
> <[EMAIL PROTECTED]> and the actual algorithm used by the i2c
> driver of the DBox code on cvs.tuxboc.org from Felix Domke
> ([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an
> of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and
> CPM2 (MPC8272).
>
> Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-cpm.c | 728
> ++
> 3 files changed, 739 insertions(+), 0 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-cpm.c
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 5fa9c3c..5c4f270 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -114,6 +114,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
> help
> The unit of the TWI clock is kHz.
>
> +config I2C_CPM
> + tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
> + depends on (CPM1 || CPM2) && PPC_OF
> + help
> + This supports the use of the I2C interface on Freescale
> + processors with CPM1 or CPM2.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-cpm.
> +
> config I2C_DAVINCI
> tristate "DaVinci I2C driver"
> depends on ARCH_DAVINCI
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index ea7068f..1291e2b 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
> obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
> +obj-$(CONFIG_I2C_CPM)+= i2c-cpm.o
> obj-$(CONFIG_I2C_DAVINCI)+= i2c-davinci.o
> obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o
> obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
> diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
> new file mode 100644
> index 000..e6e8317
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-cpm.c
> @@ -0,0 +1,728 @@
> +/*
> + * Freescale CPM1/CPM2 I2C interface.
> + * Copyright (c) 1999 Dan Malek ([EMAIL PROTECTED]).
> + *
> + * moved into proper i2c interface;
> + * Brad Parker ([EMAIL PROTECTED])
> + *
> + * (C) 2007 Montavista Software, Inc.
> + * Vitaly Bordug <[EMAIL PROTECTED]>
> + *
> + * Parts from dbox2_i2c.c (cvs.tuxbox.org)
> + * (C) 2000-2001 Felix Domke ([EMAIL PROTECTED]), Gillem ([EMAIL PROTECTED])
> + *
> + * Converted to of_platform_device. Renamed to i2c-cpm.c.
> + * (C) 2007,2008 Jochen Friedrich <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Try to define this if you have an older CPU (earlier than rev D4) */
> +/* However, better use a GPIO based bitbang driver in this case :/ */
> +#undef I2C_CHIP_ERRATA
> +
> +#define CPM_MAX_READ513
> +#define CPM_MAXBD 4
> +
> +#define CPM_CR_INIT_TRX (0x00)
> +#define CPM_CR_CLOSE_RX_BD (0x07)
> +
> +#define I2C_EB (0x10) /* Big endian mode */
> +#define I2C_EB_CPM2 (0x30) /* Big endian mode, memory snoop */
> +
> +#define DPRAM_BASE ((u8 __iomem __force *)cpm_muram_addr(0))
> +
> +/* I2C parameter RAM. */
> +struct i2c_ram {
> + ushort rbase; /* Rx Buffer descriptor base address */
> + ushort tbase; /* Tx Buffer descriptor base address */
> + u_char rfcr; /* Rx function code */
> + u_char tfcr; /* Tx function code */
> + ushort mrblr; /* Max receive buffer length */
> + uintrstate; /* Internal */
> + uintrdp;/* Internal */
> + ushort rbptr; /* Rx Buffer descriptor pointer */
> + ushort rbc;/* Internal */
> + uintrxtmp; /* Internal */
> +
Re: [Fwd: fix for drivers/serial/mpc52xx_uart.c]
On Tue, May 6, 2008 at 12:43 AM, Sylvain Munaut <[EMAIL PROTECTED]> wrote: > Patch, obviously correct, sent to me personally instead of the list. > > Sylvain > > Here is a fix for the unterminated mpc52xx_uart_of_match array when > CONFIG_PPC_MPC512x is not defined. Should be quite self explonary, but if not > feel free to bug me about it. > > Patch applies against 2.6.25 and 2.6.25.1 at least. Already fixed in mainline; it needs to be back ported to 2.6.25. I'll poke GregKH Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
On Mon, 5 May 2008 08:53:19 +0200 Stefan Roese <[EMAIL PROTECTED]> wrote: > The new 440x6 core used on AMCC 460EX/GT introduces new storage attibure > fields to the TLB2 word. Those are: > > Bit 11 12 13 14 15 > WL1 IL1I IL1D IL2I IL2D > > With these bits the cache (L1 and L2) can be configured in a more flexible > way, instruction- and data-cache independently now. The "old" I and W bits > are still available and setting these old bits will automically set these > new bits too (for backward compatibilty). > > The current code does not clear these fields resulting in disabling the cache > by chance. This patch now makes sure that these new bits are cleared when > the TLB2 word is written. > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> Finally catching back up with email. This looks like .26 material, correct? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
Hi Wolfram, >> +/* Begin transmission */ >> +setbits8(&i2c_reg->i2com, 0x80); > Hardcoded value. (I also wonder if 0x81 might be more suitable, as it > keeps the "be-a-master"-bit set. Still, both values work with my setup.) >> +#ifdef I2C_CHIP_ERRATA >> +/* >> + * Chip errata, clear enable. This is not needed on rev D4 CPUs. >> + * Disabling I2C too early may cause too short stop condition >> + */ >> +udelay(4); >> +clrbits8(&i2c_reg->i2mod, 1); > I was unable to find the corresponding errata document, still I wonder > if it is a 0 which should have been written? The text says "clear" and > according to the reference manual, this means the bit should be 0. setbits8() and clrbits8() use a bitmask as second argument. setbits8(&i2c_reg->i2com, 0x80) will set bit 7 on the i2com register but leave bit 0 untouched. Likewise, clrbits8(&i2c_reg->i2mod, 1) will clear bit 0. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH 1/2][POWERPC] PIKA Warp: Update platform code tosupportRev B boards
Opps, there is a bug in this patch. The file pika.h is not included. I have attached it below, but a simpler solution might be to just delete it from this file. It is not required to build the kernel. The file currently contains the exported dtm functions. These functions are only used by the telephony driver, which is not in the mainline kernel. Cheers, Sean Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> diff --git a/include/linux/pika.h b/include/linux/pika.h new file mode 100644 index 000..83d51df --- /dev/null +++ b/include/linux/pika.h @@ -0,0 +1,18 @@ +/* + * PIKA exported functions + * + * Copyright (c) 2008 PIKA Technologies + * Sean MacLennan <[EMAIL PROTECTED]> + */ + +#ifndef _LINUX_PIKA_H +#define _LINUX_PIKA_H + +#ifdef __KERNEL__ + +int pika_dtm_register_shutdown(void (*func)(void *arg), void *arg); +int pika_dtm_unregister_shutdown(void (*func)(void *arg), void *arg); + +#endif + +#endif ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200b MMC over SPI into PSC6
On Mon, May 5, 2008 at 12:12 PM, Fabio Tosetto <[EMAIL PROTECTED]> wrote: > Hello, I have an embedded system with an on-board processor powerpc MPC5200B > and Linux kernel 2.6.22, > I must turn over to MMC SPI on the PSC6. > > First, I > have enabled PSC6: > > in ../arch/ppc/platforms/lite5200.c added PSC6 in SPI mode You're using arch/ppc which is depreciated. You should move to using arch/powerpc (set ARCH=powerpc when compiling). Devices are then enabled in the device tree source file arch/powerpc/boot/dts/lite5200b.dts. Many things have changed with MPC5200 support in the last year, you should also use the latest kernel release (2.6.25.2 when it is released. If you use 2.6.25.1, then there is a trivial bug in the psc serial port driver that you'll need to fix. I'll include the link to the patch below) Cheers, g. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055495.html -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] Xorg crash when PCI not enabled
Hi Dan, On Tuesday 06 May 2008 11:44:12 Dan Munckton wrote: > Hi > > On Tue, 2008-05-06 at 10:14 +0200, Marvin wrote: > > p.s. I installed fc9 last week and Xorg crashes when PCI is not > > enabled. just > > in case someone has the same problem. > > The Ubuntu PS3 team is also working on an a couple of bugs relating to > lack of PCI info. I don't know if these are the same issues you're > facing. We're tracking them here at [0] and [2]. > > We had an initial crash was simple to fix [1]. Now we need to get X to > automatically load the fbdev driver instead of vesa [2]. Fedora uses a newer Xorg (1.5.0 RC1) then Ubuntu. It seems that the detection/scanning code was changed. For me, it crashes right behind "using VT number 7", where a file in /sys/bus/pci is accessed (which of course does not exist), so its not related to the other mentioned bugs. I'm hesitating to file a fedora bug report, because the default kernel works. It's more a Xorg bug to assume everyone has PCI ... Greetings Marvin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [NET] uli526x: initialize the hardware prior to requesting interrupts
Anton Vorontsov wrote: The firmware on MPC8610HPCD boards enables ULI ethernet and leaves it in some funky state before booting Linux. For drivers, it's always good idea to (re)initialize the hardware prior to requesting interrupts. This patch fixes the following oops: Oops: Kernel access of bad area, sig: 11 [#1] MPC86xx HPCD NIP: c0172820 LR: c017287c CTR: [...] NIP [c0172820] allocate_rx_buffer+0x2c/0xb0 LR [c017287c] allocate_rx_buffer+0x88/0xb0 Call Trace: [df82bdc0] [c017287c] allocate_rx_buffer+0x88/0xb0 (unreliable) [df82bde0] [c0173000] uli526x_interrupt+0xe4/0x49c [df82be20] [c0045418] request_irq+0xf0/0x114 [df82be50] [c01737b0] uli526x_open+0x48/0x160 [df82be70] [c0201184] dev_open+0xb0/0xe8 [df82be80] [c0200104] dev_change_flags+0x90/0x1bc [df82bea0] [c035fab0] ip_auto_config+0x214/0xef4 [df82bf60] [c03421c8] kernel_init+0xc4/0x2ac [df82bff0] [c0010834] kernel_thread+0x44/0x60 Instruction dump: 4e800020 9421ffe0 7c0802a6 bfa10014 7c7e1b78 90010024 80030060 83e30054 2b80002f 419d0078 3fa0c039 4858 <907f0010> 80630088 2f83 419e0014 Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- drivers/net/tulip/uli526x.c |8 1 files changed, 4 insertions(+), 4 deletions(-) applied 1-2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Delete unused fec_8xx net driver
Becky Bruce wrote: This driver has been superseded by fs_enet and is no longer in use. Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> I cannot make an informed judgement on this. ACK, and pass through platform tree, if all platform peeps are happy. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Sam440ep support
I've prepared another path to add the support for the sam440ep;
shortly I've merged arch/powerpc/boot/sam440ep.c in
arch/powerpc/boot/cuboot-sam440ep.c; I've inserted the code to make
the rtc works directly in arch/powerpc/platforms/44x/sam440ep.c (so
there isn't any arch/powerpc/sysdev/sam440ep.c anymore), and I've
cutted away the nasty hack (dma-mapping.h and memmalloc.c) to make the
sound works.
arch/powerpc/boot/Makefile |3 +-
arch/powerpc/boot/cuboot-sam440ep.c | 49 ++
arch/powerpc/boot/dts/sam440ep.dts | 292 +++
arch/powerpc/configs/44x/sam440ep_defconfig | 1192 +++
arch/powerpc/platforms/44x/Kconfig |9 +
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/sam440ep.c | 80 ++
7 files changed, 1625 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7822d25..e79f397 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -66,7 +66,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c
cuboot-83xx.c cuboot-85xx.c holly.c
fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c
\
- virtex405-head.S
+ virtex405-head.S cuboot-sam440ep.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -213,6 +213,7 @@ image-$(CONFIG_WALNUT) +=
treeImage.walnut
# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
+image-$(CONFIG_SAM440EP) += cuImage.sam440ep
image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
image-$(CONFIG_RAINIER)+= cuImage.rainier
image-$(CONFIG_TAISHAN)+= cuImage.taishan
diff --git a/arch/powerpc/boot/cuboot-sam440ep.c
b/arch/powerpc/boot/cuboot-sam440ep.c
new file mode 100644
index 000..7aa61a3
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-sam440ep.c
@@ -0,0 +1,49 @@
+/*
+ * Old U-boot compatibility for Sam440ep based off bamboo.c code
+ * original copyrights below
+ *
+ * Author: Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * Copyright 2007 IBM Corporation
+ *
+ * Based on cuboot-ebony.c
+ *
+ * Modified from cuboot-bamboo.c for sam440ep:
+ * Copyright 2008 Giuseppe Coviello <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "44x.h"
+#include "4xx.h"
+#include "cuboot.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void sam440ep_fixups(void)
+{
+ unsigned long sysclk = ;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 2500);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = sam440ep_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
diff --git a/arch/powerpc/boot/dts/sam440ep.dts
b/arch/powerpc/boot/dts/sam440ep.dts
new file mode 100644
index 000..764cab0
--- /dev/null
+++ b/arch/powerpc/boot/dts/sam440ep.dts
@@ -0,0 +1,292 @@
+/*
+ * Device Tree Source for ACube Sam440ep based off bamboo.dts code
+ * original copyrights below
+ *
+ * Copyright (c) 2006, 2007 IBM Corp.
+ * Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * Modified from bamboo.dts for sam440ep:
+ * Copyright 2008 Giuseppe Coviello <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "acube,sam440ep";
+ compatible = "acube,sam440ep";
+ dcr-parent = <&/cpus/[EMAIL PROTECTED]>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ serial2 = &UART2;
+ serial3 = &UART3;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ device_type = "cpu";
+ model = "PowerPC,440EP";
+ reg = <0>;
+ clock
Re: [PATCH] [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
On Tuesday 06 May 2008, Josh Boyer wrote: > > The new 440x6 core used on AMCC 460EX/GT introduces new storage attibure > > fields to the TLB2 word. Those are: > > > > Bit 11 12 13 14 15 > > WL1 IL1I IL1D IL2I IL2D > > > > With these bits the cache (L1 and L2) can be configured in a more > > flexible way, instruction- and data-cache independently now. The "old" I > > and W bits are still available and setting these old bits will > > automically set these new bits too (for backward compatibilty). > > > > The current code does not clear these fields resulting in disabling the > > cache by chance. This patch now makes sure that these new bits are > > cleared when the TLB2 word is written. > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > Finally catching back up with email. This looks like .26 material, > correct? Definitely, yes. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
On Tue, May 06, 2008 at 05:19:39PM +0200, Jochen Friedrich wrote: > setbits8() and clrbits8() use a bitmask as second argument. Ouch! Guess my mind wanted to read in_8 and out_8 for some reason... Sorry and thanks for clarifying! Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 2/4] [POWERPC] Xilinx: Virtex: Enable dcr for MMIO andNATIVE
Yes, but this is a symptom of a separate problem, which is that it is sometimes valuable to generate an optimized kernel configuration for a particular FPGA system. First order, I'm more concerned about getting a kernel which is generic and can work with (more or less) any device tree. Steve > -Original Message- > From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] > Sent: Monday, May 05, 2008 5:12 PM > To: Stephen Neuendorffer > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org > Subject: Re: [PATCH 2/4] [POWERPC] Xilinx: Virtex: Enable dcr for MMIO andNATIVE > > > On Mon, 2008-05-05 at 10:56 -0700, Stephen Neuendorffer wrote: > > FPGA designs may have need of both MMIO-based and NATIVE-based dcr > > interfaces. > > You say _may_ ... wouldn't it be better if it was thus left to a given > virtex based platform to enable DCR_MMIO if it uses it and leave only > NATIVE by default ? > > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > > --- > > arch/powerpc/platforms/40x/Kconfig |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig > > index a9260e2..b8e06df 100644 > > --- a/arch/powerpc/platforms/40x/Kconfig > > +++ b/arch/powerpc/platforms/40x/Kconfig > > @@ -123,6 +123,8 @@ config 405GPR > > > > config XILINX_VIRTEX > > bool > > + select PPC_DCR_MMIO > > + select PPC_DCR_NATIVE > > > > config XILINX_VIRTEX_II_PRO > > bool > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/4] [v4][POWERPC] refactor dcr code
I'll fix it. > -Original Message- > From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] > Sent: Monday, May 05, 2008 9:02 PM > To: Stephen Rothwell > Cc: Stephen Neuendorffer; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc- > [EMAIL PROTECTED] > Subject: Re: [PATCH 1/4] [v4][POWERPC] refactor dcr code > > > On Tue, 2008-05-06 at 13:40 +1000, Stephen Rothwell wrote: > > Since find_dcr_parent has done a of_node_get on its return value, you > > leak a reference to dp here i.e. you need an of_node_put(dp) before > > you return. > > He inherited that bug from other dcr.c functions I wrote, my fault. > > Stephen (N. not R.), would you mind fixing them while at it or do you > want me to cook up a patch ? > > Cheers, > Ben. > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [v4][POWERPC] refactor dcr code
On Tue, 6 May 2008 10:34:36 -0700 "Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote: > > I'll fix it. Great. Otherwise the patch looks pretty good in my review. I'll queue it up for 2.6.27. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure.
> -Original Message-
> From: David Gibson [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 05, 2008 11:15 PM
> To: Grant Likely
> Cc: Stephen Neuendorffer; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use
dcrinfrastructure.
>
> On Mon, May 05, 2008 at 10:55:53PM -0600, Grant Likely wrote:
> > On Mon, May 5, 2008 at 11:56 AM, Stephen Neuendorffer
> > <[EMAIL PROTECTED]> wrote:
> > > This device contains a dcr interface. Previously, the dcr
interface
> > > was assumed to be used in mmio mode, and the register space of
the dcr
> > > interface was precomputed and stuffed in the device tree. This
patch
> > > makes use of the new dcr infrastructure to represent the dcr
interface
> > > as any other dcr interface in the device tree. This enables the
dcr
> > > interface to be connected directly to a native dcr interface in a
> > > clean way.
> > >
> > > In particular, the device tree expected looks like:
> > >
> > > dcr_v29_0: [EMAIL PROTECTED] {
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > compatible =
"xlnx,dcr-v29-1.00.a";
> > > VGA_FrameBuffer: [EMAIL PROTECTED] {
> > > compatible =
"xlnx,plb-tft-cntlr-ref-1.00.a";
> > > dcr-parent =
<&opb2dcr_bridge_0>;
> > > dcr-reg = < 80 2 >;
> > > xlnx,default-tft-base-addr
= <7f>;
> > > xlnx,dps-init = <1>;
> > > xlnx,on-init = <1>;
> > >
xlnx,pixclk-is-busclk-divby4 = <1>;
> > > } ;
> > > } ;
> > >
> > > opb2dcr_bridge_0: [EMAIL PROTECTED]
{
> > > compatible =
"xlnx,opb2dcr-bridge-1.00.b";
> > > dcr-access-method = "mmio";
> > > dcr-controller ;
> > > dcr-mmio-range = < 4070 1000
>;
> > > dcr-mmio-stride = <4>;
> > > reg = < 4070 1000 >;
> > > xlnx,family = "virtex2p";
> > > } ;
> >
> > Hmmm, something doesn't quite feel right about this. The node
> > describing the tft device is a child of the [EMAIL PROTECTED] node which is
> > the
> > dcr bus. However, dcr bindings use dcr-bus and dcr-reg instead of
> > parent-child relationship to specify how to access the dcr
registers.
> > So, in this example; if the device is described by [EMAIL PROTECTED], and
> > the
dcr
> > bus is described by [EMAIL PROTECTED], then what does [EMAIL PROTECTED]
> > describe? (I do understand what they really describe in EDK terms;
> > but I'm looking at it through device tree glasses).
> >
> > I don't think the presence of a [EMAIL PROTECTED] node is a problem, but in
> > this
> > case #size/address-cells doesn't have any meaning (the child doesn't
> > have a reg property) and it looks like it should be a child of the
> > opb2dcr-bridge node (otherwise, what is it attached to?).
>
> Yes, indeed. If [EMAIL PROTECTED] is representing the DCR bus / interface it
> should really have the dcr-access-method property and have all the
> dcr-parent handles point at it.
Hmm, I tend to agree. Certainly the address-cells and size-cells can
go. Part of the nastiness is that I'm trying to maintain a modicum of
backward compatibility at the moment in the device tree generator. This
structure allow the [EMAIL PROTECTED] node to have ranges; and the tft node to
have
a properly translated reg = <> property for the existing driver which
only understands mmio. I don't think it really works for the opb2dcr
bridge to be a bridge and a dcr-controller at the same time. :) This
structure is also very similar to what is generated if the
dcr-controller is native from the processor (there's just no bridge).
> Current standard practice is not to represent the DCR bus as node with
> subnodes for the DCR-controlled devices. That's because the DCR bus
> tends to run in addition to other on-chip busses, and some things have
> to go on another on-chip bus to make sense, but still have DCR control
> registers (for example the internal bus bridges on 4xx).
>
> Arguably for DCR-only devices we should instead have a node
> representing the DCR bus and just put the devices under it with the
> DCR number encoded in reg in the normal way. But then its
> inconsistent with the devices that need the other DCR representation.
Yup, it's exactly this problem I'm trying to fix in the case of the tft
driver.
> Segher and I did toss around some ideas for generalizing the DCR
> representation to a way of representing that any node has some
> p
RE: [PATCH] Xilinx: hwicap: cleanup polling timeout.
Not really... In this case 'faster' means 'faster ICAP core' not 'faster
processor':
This is really something that is bounded by the number of cycles.
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Monday, May 05, 2008 1:01 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Xilinx: hwicap: cleanup polling timeout.
>
> On Mon, May 5, 2008 at 12:20 PM, Stephen Neuendorffer
> <[EMAIL PROTECTED]> wrote:
> > In order to avoid polling forever if an error occurs, this driver
> > includes a timeout counter. However, in fast systems, this counter
> > wasn't high enough. This patch fixes the bug and also makes the
> > buffer-based and fifo-based drivers return the same error condition
on
> > a timeout (-EIO).
>
> Would it be better to base the timeout on real time instead of a hard
> iteration count?
>
> Cheers,
> g.
>
> >
> > Signed-off-by: Stephen Neuendorffer
<[EMAIL PROTECTED]>
> > ---
> > drivers/char/xilinx_hwicap/buffer_icap.c | 10 --
> > drivers/char/xilinx_hwicap/fifo_icap.c |9 +
> > drivers/char/xilinx_hwicap/xilinx_hwicap.h |3 ---
> > 3 files changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c
b/drivers/char/xilinx_hwicap/buffer_icap.c
> > index aa7f796..0993883 100644
> > --- a/drivers/char/xilinx_hwicap/buffer_icap.c
> > +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
> > @@ -35,6 +35,12 @@
> >
> > #include "buffer_icap.h"
> >
> > +/* Number of times to poll the done register. This has to be
large
> > + enough to allow an entire configuration to complete. If an
entire
> > + page (4kb) is configured at once, that could take up to 4k
cycles
> > + with a byte-wide icap interface. */
> > +#define XHI_MAX_RETRIES 5000
> > +
> > /* Indicates how many bytes will fit in a buffer. (1 BRAM) */
> > #define XHI_MAX_BUFFER_BYTES2048
> > #define XHI_MAX_BUFFER_INTS (XHI_MAX_BUFFER_BYTES >> 2)
> > @@ -208,7 +214,7 @@ static int buffer_icap_device_read(struct
hwicap_drvdata *drvdata,
> > while (buffer_icap_busy(base_address)) {
> > retries++;
> > if (retries > XHI_MAX_RETRIES)
> > - return -EBUSY;
> > + return -EIO;
> > }
> > return 0;
> >
> > @@ -242,7 +248,7 @@ static int buffer_icap_device_write(struct
hwicap_drvdata *drvdata,
> > while (buffer_icap_busy(base_address)) {
> > retries++;
> > if (retries > XHI_MAX_RETRIES)
> > - return -EBUSY;
> > + return -EIO;
> > }
> > return 0;
> >
> > diff --git a/drivers/char/xilinx_hwicap/fifo_icap.c
b/drivers/char/xilinx_hwicap/fifo_icap.c
> > index 776b505..d1cd928 100644
> > --- a/drivers/char/xilinx_hwicap/fifo_icap.c
> > +++ b/drivers/char/xilinx_hwicap/fifo_icap.c
> > @@ -35,6 +35,15 @@
> >
> > #include "fifo_icap.h"
> >
> > +/* Number of times to poll the done register. This has to be
large
> > + * enough to allow an entire configuration to complete. If an
entire
> > + * page (4kb) is configured at once, that could take up to 4k
cycles
> > + * with a byte-wide icap interface. In most cases, this driver is
> > + * used with a much smaller fifo, but this should be sufficient in
the
> > + * worst case.
> > + */
> > +#define XHI_MAX_RETRIES 5000
> > +
> > /* Register offsets for the XHwIcap device. */
> > #define XHI_GIER_OFFSET0x1C /* Device Global Interrupt
Enable Reg */
> > #define XHI_IPISR_OFFSET 0x20 /* Interrupt Status Register */
> > diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.h
> b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
> > index 1f9c8b0..fd4be31 100644
> > --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.h
> > +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
> > @@ -89,9 +89,6 @@ struct hwicap_driver_config {
> > void (*reset)(struct hwicap_drvdata *drvdata);
> > };
> >
> > -/* Number of times to poll the done regsiter */
> > -#define XHI_MAX_RETRIES 10
> > -
> > / Constant Definitions */
> >
> > #define XHI_PAD_FRAMES 0x1
> > --
> > 1.5.3.4-dirty
> >
> >
> >
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] [v5][POWERPC] refactor dcr code
Previously, dcr support was configured at compile time to either using
MMIO or native dcr instructions. Although this works for most
platforms, it fails on FPGA platforms:
1) Systems may include more than one dcr bus.
2) Systems may be native dcr capable and still use memory mapped dcr interface.
This patch provides runtime support based on the device trees for the
case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both
selected. Previously, this was a poorly defined configuration, which
happened to provide NATIVE support. The runtime selection is made
based on the dcr controller having a 'dcr-access-method' attribute
in the device tree. If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid introducing overhead in existing usage.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
--
[v4]
Converted flags to be DCR_HOST_*
Added WARN_ON in case someone forgets to call MAP_OK()
Fixed dealing with the dcr-access-method correctly, which was still
off in the wrong patch.
[v5]
Fixed leaked reference to the device tree.
---
arch/powerpc/sysdev/dcr.c | 154 +
include/asm-powerpc/dcr-generic.h | 49
include/asm-powerpc/dcr-mmio.h| 20 +++--
include/asm-powerpc/dcr-native.h | 16 +++--
include/asm-powerpc/dcr.h | 39 +-
5 files changed, 231 insertions(+), 47 deletions(-)
create mode 100644 include/asm-powerpc/dcr-generic.h
diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
index 437e48d..5f39a79 100644
--- a/arch/powerpc/sysdev/dcr.c
+++ b/arch/powerpc/sysdev/dcr.c
@@ -23,6 +23,105 @@
#include
#include
+static struct device_node *find_dcr_parent(struct device_node *node)
+{
+ struct device_node *par, *tmp;
+ const u32 *p;
+
+ for (par = of_node_get(node); par;) {
+ if (of_get_property(par, "dcr-controller", NULL))
+ break;
+ p = of_get_property(par, "dcr-parent", NULL);
+ tmp = par;
+ if (p == NULL)
+ par = of_get_parent(par);
+ else
+ par = of_find_node_by_phandle(*p);
+ of_node_put(tmp);
+ }
+ return par;
+}
+
+#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
+
+bool dcr_map_ok_generic(dcr_host_t host)
+{
+ if (host.type == DCR_HOST_NATIVE)
+ return dcr_map_ok_native(host.host.native);
+ else if (host.type == DCR_HOST_MMIO)
+ return dcr_map_ok_mmio(host.host.mmio);
+ else
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
+
+dcr_host_t dcr_map_generic(struct device_node *dev,
+ unsigned int dcr_n,
+ unsigned int dcr_c)
+{
+ dcr_host_t host;
+ struct device_node *dp;
+ const char *prop;
+
+ host.type = DCR_HOST_INVALID;
+
+ dp = find_dcr_parent(dev);
+ if (dp == NULL)
+ return host;
+
+ prop = of_get_property(dp, "dcr-access-method", NULL);
+
+ pr_debug("dcr_map_generic(dcr-access-method = %s)\n", prop);
+
+ if (!strcmp(prop, "native")) {
+ host.type = DCR_HOST_NATIVE;
+ host.host.native = dcr_map_native(dev, dcr_n, dcr_c);
+ } else if (!strcmp(prop, "mmio")) {
+ host.type = DCR_HOST_MMIO;
+ host.host.mmio = dcr_map_mmio(dev, dcr_n, dcr_c);
+ }
+
+ of_node_put(dp);
+ return host;
+}
+EXPORT_SYMBOL_GPL(dcr_map_generic);
+
+void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
+{
+ if (host.type == DCR_HOST_NATIVE)
+ dcr_unmap_native(host.host.native, dcr_c);
+ else if (host.type == DCR_HOST_MMIO)
+ dcr_unmap_mmio(host.host.mmio, dcr_c);
+ else /* host.type == DCR_HOST_INVALID */
+ WARN_ON(true);
+}
+EXPORT_SYMBOL_GPL(dcr_unmap_generic);
+
+u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n)
+{
+ if (host.type == DCR_HOST_NATIVE)
+ return dcr_read_native(host.host.native, dcr_n);
+ else if (host.type == DCR_HOST_MMIO)
+ return dcr_read_mmio(host.host.mmio, dcr_n);
+ else /* host.type == DCR_HOST_INVALID */
+ WARN_ON(true);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dcr_read_generic);
+
+void dcr_write_generic(dcr_host_t host, unsigned int dcr_n, u32 value)
+{
+ if (host.type == DCR_HOST_NATIVE)
+ dcr_write_native(host.host.native, dcr_n, value);
+ else if (host.type == DCR_HOST_MMIO)
+ dcr_write_mmio(host.host.mmio, dcr_n, value);
+ else /* host.type == DCR_HOST_INVALID */
+ WARN_ON(true);
+}
+EXPORT_SYMBOL_GPL(dcr_write_generic);
+
+#endif /* defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO) */
+
unsigned int dcr_resource_start(struct device_node *np, unsigned
Re: [PATCH] [POWERPC] Fix of_i2c include for module compilation
Hi Paul, >> -#ifdef CONFIG_OF_I2C >> +#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE) >> >> void of_register_i2c_devices(struct i2c_adapter *adap, >> struct device_node *adap_node); > > Why do we have that ifdef there at all? There's only that one > external declaration within it, so the #ifdef and #endif could just be > removed. If the ifdef hadn't been there in the first place we > wouldn't have had this problem. You're right. I mainly copied from of_gpio.h without too much thinking :(. I'll resend. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 2.6.26-rc1] [POWERPC] Fix of_i2c include for module compilation
Remove #ifdef CONFIG_OF_I2C as this breaks module compilation. Drivers using this header should depend on OF_I2C anyways, so there's no need to make this conditional Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> --- include/linux/of_i2c.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h index 2e5a967..bd2a870 100644 --- a/include/linux/of_i2c.h +++ b/include/linux/of_i2c.h @@ -14,11 +14,7 @@ #include -#ifdef CONFIG_OF_I2C - void of_register_i2c_devices(struct i2c_adapter *adap, struct device_node *adap_node); -#endif /* CONFIG_OF_I2C */ - #endif /* __LINUX_OF_I2C_H */ -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] gianfar: low gigabit throughput
Hi all, Down here few question regarding networking throughput, I would appreciate any thoughts or ideas. On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing relatively low TCP throughput using gianfar driver... The maximum value I've seen with the current kernels is 142 Mb/s of TCP and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled): [EMAIL PROTECTED]:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344 TCP STREAM TEST to 10.0.1.1 #Cpu utilization 0.10 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 206848 212992 3276810.00 142.40 [EMAIL PROTECTED]:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344 UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1 #Cpu utilization 100.00 Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 212992 32768 10.00 13539 0 354.84 206848 10.00 13539354.84 Is this normal? netperf running in loopback gives me 329 Mb/s of TCP throughput: [EMAIL PROTECTED]:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344 TCP STREAM TEST to 127.0.0.1 #Cpu utilization 100.00 #Cpu utilization 100.00 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 212992 212992 3276810.00 329.60 May I consider this as a something that is close to the Linux' theoretical maximum for this setup? Or this isn't reliable test? I can compare with teh MPC8377E-RDB (very similar board - exactly the same ethernet phy, the same drivers are used, i.e. everything is the same from the ethernet stand point), but running at 666 MHz, CSB at 333MHz: |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s| -- MPC8377|666|333| 646| 264| MPC8315|400|133| 354| 142| -- RATIO |1.6|2.5| 1.8| 1.8| It seems that things are really dependant on the CPU/CSB speed. I've tried to tune gianfar driver in various ways... and it gave some positive results with this patch: diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index fd487be..b5943f9 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -123,8 +123,8 @@ extern const char gfar_driver_version[]; #define GFAR_10_TIME25600 #define DEFAULT_TX_COALESCE 1 -#define DEFAULT_TXCOUNT16 -#define DEFAULT_TXTIME 21 +#define DEFAULT_TXCOUNT80 +#define DEFAULT_TXTIME 105 #define DEFAULT_RXTIME 21 Basically this raises the tx interrupts coalescing threshold (raising it more didn't help, as well as didn't help raising rx thresholds). Now: [EMAIL PROTECTED]:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344 TCP STREAM TEST to 10.0.1.1 #Cpu utilization 100.00 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 206848 212992 327683.00 163.04 That is +21 Mb/s (14% up). Not fantastic, but good anyway. As expected, the latency increased too: Before the patch: --- 10.0.1.1 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 18997ms rtt min/avg/max/mdev = 0.108/0.124/0.173/0.022 ms After: --- 10.0.1.1 ping statistics --- 22 packets transmitted, 22 received, 0% packet loss, time 20997ms rtt min/avg/max/mdev = 0.158/0.167/0.182/0.004 ms 34% up... heh. Should we sacrifice the latency in favour of throughput? Is 34% latency growth bad thing? What is worse, lose 21 Mb/s or 34% of latency? ;-) Thanks in advance, p.s. Btw, the patch above helps even better on the on the -rt kernels, since on the -rt kernels the throughput is near 100 Mb/s, with the patch the throughput is close to 140 Mb/s. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
On Tue, 6 May 2008 18:41:44 +0200 Stefan Roese <[EMAIL PROTECTED]> wrote: > On Tuesday 06 May 2008, Josh Boyer wrote: > > > The new 440x6 core used on AMCC 460EX/GT introduces new storage attibure > > > fields to the TLB2 word. Those are: > > > > > > Bit 11 12 13 14 15 > > > WL1 IL1I IL1D IL2I IL2D > > > > > > With these bits the cache (L1 and L2) can be configured in a more > > > flexible way, instruction- and data-cache independently now. The "old" I > > > and W bits are still available and setting these old bits will > > > automically set these new bits too (for backward compatibilty). > > > > > > The current code does not clear these fields resulting in disabling the > > > cache by chance. This patch now makes sure that these new bits are > > > cleared when the TLB2 word is written. > > > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > > > Finally catching back up with email. This looks like .26 material, > > correct? > > Definitely, yes. Figured. I have it queued up. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'for-2.6.26' branch of 4xx tree
Hi Paul, Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26 to pick up a small number of fixes for 4xx. One corrects the PCI addresses for Sequoia boards, another fixes TLB issues with newer 440x6 cores. Stefan's pci-e endpoint driver is also included here as it is a fairly contained change with Ben's Ack. It should have been included in my last pull request, but I missed it and have been out. thx, josh Christian Ehrhardt (1): [POWERPC] 4xx: Fix PCI mem in sequoia DTS Stefan Roese (2): [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 c [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver arch/powerpc/boot/dts/sequoia.dts |9 ++- arch/powerpc/kernel/head_44x.S |9 ++- arch/powerpc/sysdev/ppc4xx_pci.c| 180 +-- include/asm-powerpc/pgtable-ppc32.h |7 ++ 4 files changed, 153 insertions(+), 52 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
arch/ppc is broken
Every arch/ppc defconfig I built today failed. Someone broke it. Those interested in fixing it might want to see why. I suspect the ppc/powerpc: use kbuild.h instead of defining macros in asm-offsets.c is responsible, but I have no evidence of that. josh /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:152: error: '__flush_icache_range' undeclared here (not in a function) /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:152: warning: type defaults to 'int' in declaration of '__flush_icache_range' /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:153: error: 'flush_dcache_range' undeclared here (not in a function) /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:153: warning: type defaults to 'int' in declaration of 'flush_dcache_range' /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:154: error: 'flush_icache_user_range' undeclared here (not in a function) /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:154: warning: type defaults to 'int' in declaration of 'flush_icache_user_range' /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:155: error: 'flush_dcache_page' undeclared here (not in a function) /home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:155: warning: type defaults to 'int' in declaration of 'flush_dcache_page' make[2]: *** [arch/ppc/kernel/ppc_ksyms.o] Error 1 /home/jwboyer/src/linux-2.6/arch/powerpc/kernel/prom_init.c:130: error: expected specifier-qualifier-list before 'ihandle' ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] gianfar: low gigabit throughput
Anton Vorontsov wrote: Hi all, Down here few question regarding networking throughput, I would appreciate any thoughts or ideas. On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing relatively low TCP throughput using gianfar driver... What is the "target" of the test - is it another of those boards, or something else? The maximum value I've seen with the current kernels is 142 Mb/s of TCP and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled): [EMAIL PROTECTED]:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344 TCP STREAM TEST to 10.0.1.1 #Cpu utilization 0.10 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 206848 212992 3276810.00 142.40 [EMAIL PROTECTED]:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344 UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1 #Cpu utilization 100.00 Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 212992 32768 10.00 13539 0 354.84 206848 10.00 13539354.84 I have _got_ to make CPU utilization enabled by default one of these days :) At least for mechanisms which don't require calibration. Is this normal? Does gianfar do TSO? If not, what happens when you tell UDP_STREAM to send 1472 byte messages to bypass IP fragmentation? While stock netperf won't report what the socket buffer size becomes when you allow autotuning to rear its head, you can take the top of trunk and enable the "omni" tests (./configure --enable-omni) and those versions of *_STREAM etc can report what the socket buffer size was at the beginning and at the end of the test. You can let the stack autotune and see if anything changes there. You can do the same with stock netperf, just it will only report the initial socket buffer sizes... netperf running in loopback gives me 329 Mb/s of TCP throughput: [EMAIL PROTECTED]:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344 TCP STREAM TEST to 127.0.0.1 #Cpu utilization 100.00 #Cpu utilization 100.00 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 212992 212992 3276810.00 329.60 May I consider this as a something that is close to the Linux' theoretical maximum for this setup? Or this isn't reliable test? I'm always leery of using a loopback number. It excercises both send and receive at the same time, but without the driver. Also, lo tends to have a much larger MTU than a "standard" NIC and if that NIC doesn't to TSO and LRO that can be a big difference in the number of times up and down the stack per KB transferred. I can compare with teh MPC8377E-RDB (very similar board - exactly the same ethernet phy, the same drivers are used, i.e. everything is the same from the ethernet stand point), but running at 666 MHz, CSB at 333MHz: |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s| -- MPC8377|666|333| 646| 264| MPC8315|400|133| 354| 142| -- RATIO |1.6|2.5| 1.8| 1.8| It seems that things are really dependant on the CPU/CSB speed. What is the nature of the DMA stream between the two tests? I find it interesting that the TCP Mb/s went up by more than the CPU MHz and wonder how much the Bus MHz came into play there - perhaps there were more DMA's to setup or across a broader memory footprint for TCP than for UDP. I've tried to tune gianfar driver in various ways... and it gave some positive results with this patch: diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index fd487be..b5943f9 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -123,8 +123,8 @@ extern const char gfar_driver_version[]; #define GFAR_10_TIME25600 #define DEFAULT_TX_COALESCE 1 -#define DEFAULT_TXCOUNT16 -#define DEFAULT_TXTIME 21 +#define DEFAULT_TXCOUNT80 +#define DEFAULT_TXTIME 105 #define DEFAULT_RXTIME 21 No ethtool coalescing tuning support for gianfar?-) Basically this raises the tx interrupts coalescing threshold (raising it more didn't help, as well as didn't help raising rx thresholds). Now: [EMAIL PROTECTED]:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344 TCP STREAM TEST to 10.0.1.1 #Cpu utilization 100.00 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 206848 212992 327683.00 163.04 That is +21 Mb/s (14% up). Not fantastic, but good anyway. As expected, the latency increased too: Before the patch: --- 10.0.1.1 ping stat
Re: [RFC] gianfar: low gigabit throughput
I've tried to tune gianfar driver in various ways... and it gave some positive results with this patch: diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h index fd487be..b5943f9 100644 --- a/drivers/net/gianfar.h +++ b/drivers/net/gianfar.h @@ -123,8 +123,8 @@ extern const char gfar_driver_version[]; #define GFAR_10_TIME25600 #define DEFAULT_TX_COALESCE 1 -#define DEFAULT_TXCOUNT16 -#define DEFAULT_TXTIME 21 +#define DEFAULT_TXCOUNT80 +#define DEFAULT_TXTIME 105 #define DEFAULT_RXTIME 21 No ethtool coalescing tuning support for gianfar?-) Yeah, there's coalescing tuning in gianfar. Anton, those numbers aren't too surprising on a 400 MHz machine, I think. But I'd be happy to see any analysis on performance bottlenecks in the driver. And patches to fix those bottlenecks are even better! :) Andy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Strange build error in boot/wrapper script
Hi, I get a rather strange error here with kernel v2.6.26-rc1 and gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (cross compile version). This is the output of the build process: > $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CALLscripts/checksyscalls.sh > CHK include/linux/compile.h > CALLarch/powerpc/kernel/systbl_chk.sh > CALLarch/powerpc/kernel/prom_init_check.sh > WRAParch/powerpc/boot/uImage > Image Name: Linux-2.6.26-rc1 > Created: Tue May 6 22:43:54 2008 > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size:1780300 Bytes = 1738.57 kB = 1.70 MB > Load Address: 0x > Entry Point: 0x > arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/amigaone.dtb -b 0 > /home/geri/AmigaOne/Linux/linux-2.6.26/arch/powerpc/boot/dts/amigaone.dts > DTC: dts->dtb on file > "/home/geri/AmigaOne/Linux/linux-2.6.26/arch/powerpc/boot/dts/amigaone.dts" > WRAParch/powerpc/boot/cuImage.amigaone > powerpc-linux-gnu-objcopy: Warning: could not locate './vmlinux.strip'. > reason: The value is too big for the defined data type (translated to English) > Image Name: Linux-2.6.26-rc1 > Created: Tue May 6 22:43:54 2008 > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size:21675 Bytes = 21.17 kB = 0.02 MB > Load Address: 0x0040 > Entry Point: 0x00400444 > rm arch/powerpc/boot/amigaone.dtb As you can see, the wrapper script generates an incomplete cuImage. The vmlinux.strip file is there, but I wonder why it is so big: > -rw-r--r-- 3225085348 2008-05-06 21:58 vmlinux.strip Any ideas what is going wrong here? Broken compiler? Thanks! regards, Gerhard -- 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro. Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ifconfig MPC8313
Hello all, I am working on porting linux 2.6.25 with a custom MPC8313 based board, but am having a little bit of trouble with the ethernet, more specifically ifconfig. after typing "ifconfig eth0 10.196.31.84" I receive the following error ifconfig: SIOCSIFFLAGS: Cannot assign requested address after entering a MAC address via "ifconfig eth0 hw ether" I receive this error. e0024520:01 not found eth0: Could not attach to PHY ifconfig: SIOCSIFFLAGS: No such device which I have traced to bus_find_device, but I'm not sure what to make of this. I'm not sure where I'm going wrong here, and I'm sure that it's something that I'm forgetting to do/include. Sorry if this isn't enough information, but I don't know enough to know what other information would be needed. Ron _ Get Free (PRODUCT) RED™ Emoticons, Winks and Display Pics. http://joinred.spaces.live.com?ocid=TXT_HMTG_prodredemoticons_052008___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ifconfig MPC8313
Ronald Madrid wrote: Hello all, I am working on porting linux 2.6.25 with a custom MPC8313 based board, but am having a little bit of trouble with the ethernet, more specifically ifconfig. after typing "ifconfig eth0 10.196.31.84" I receive the following error ifconfig: SIOCSIFFLAGS: Cannot assign requested address after entering a MAC address via "ifconfig eth0 hw ether" I receive this error. e0024520:01 not found eth0: Could not attach to PHY ifconfig: SIOCSIFFLAGS: No such device It can't find the PHY for eth0. What does your device tree look like, and what is the relevant PHY address? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: ifconfig MPC8313
I'm guessing by device tree you mean the .dts file? I'm using a modified
version of the mpc8313erdb.dts with minor changes (to the local bus only).
Here is a copy of it./* * MPC8313E RDB Device Tree Source * * Copyright 2005,
2006, 2007 Freescale Semiconductor Inc. * * This program is free software; you
can redistribute it and/or modify it * under the terms of the GNU General
Public License as published by the * Free Software Foundation; either version
2 of the License, or (at your * option) any later version. *//dts-v1/;/ {
model = "MPC8313ERDB";compatible = "MPC8313ERDB", "MPC831xRDB",
"MPC83xxRDB";#address-cells = <1>;#size-cells = <1>;aliases {
ethernet0 = &enet0;ethernet1 = &enet1;serial0 = &serial0;
serial1 = &serial1;pci0 = &pci0;};cpus {
#address-cells = <1>;#size-cells = <0>;PowerPC,[EMAIL
PROTECTED] {device_type = "cpu";reg = <0x0>;
d-cache-line-size = <32>;i-cache-line-size = <32>;
d-cache-size = <16384>;i-cache-size = <16384>;
timebase-frequency = <0>;// from bootloaderbus-frequency = <0>;
// from bootloaderclock-frequency = <0>;// from
bootloader};};memory {device_type = "memory";
reg = <0x 0x0800>;// 128MB at 0};[EMAIL PROTECTED] {
#address-cells = <2>;#size-cells = <1>;compatible =
"fsl,mpc8313-elbc", "fsl,elbc", "simple-bus";reg = <0xe0005000 0x1000>;
interrupts = <77 0x8>;interrupt-parent = <&ipic>;// CS0
and CS1 are swapped when// booting from nand, but the//
addresses are the same.//ranges = <0x0 0x0 0xfe00 0x0080//
0x1 0x0 0xe280 0x8000// 0x2 0x0 0xf000
0x0002// 0x3 0x0 0xfa00 0x8000>;ranges =
<0x0 0x0 0xe280 0x8000>;//[EMAIL PROTECTED],0 {//
#address-cells = <1>;//#size-cells = <1>;//compatible =
"cfi-flash";//reg = <0x0 0x0 0x80>;//bank-width =
<2>;//device-width = <1>;//};//[EMAIL PROTECTED],0
{[EMAIL PROTECTED],0 {#address-cells = <1>;
#size-cells = <1>;compatible = "fsl,mpc8313-fcm-nand",
"fsl,elbc-fcm-nand";//reg = <0x1 0x0 0x2000>;
reg = <0x0 0x0 0x2000>;[EMAIL PROTECTED] {reg =
<0x0 0x10>;read-only;};[EMAIL
PROTECTED] {reg = <0x10 0x30>;};
[EMAIL PROTECTED] {reg = <0x40 0x1c0>;};
};};[EMAIL PROTECTED] {#address-cells = <1>;
#size-cells = <1>;device_type = "soc";compatible =
"simple-bus";ranges = <0x0 0xe000 0x0010>;reg =
<0xe000 0x0200>;bus-frequency = <0>;[EMAIL PROTECTED] {
device_type = "watchdog";compatible = "mpc83xx_wdt";
reg = <0x200 0x100>;};[EMAIL PROTECTED] {
#address-cells = <1>;#size-cells = <0>;cell-index =
<0>;compatible = "fsl-i2c";reg = <0x3000 0x100>;
interrupts = <14 0x8>;interrupt-parent = <&ipic>;
dfsrr;[EMAIL PROTECTED] {compatible =
"dallas,ds1339";reg = <0x68>;};};
[EMAIL PROTECTED] {#address-cells = <1>;#size-cells =
<0>;cell-index = <1>;compatible = "fsl-i2c";
reg = <0x3100 0x100>;interrupts = <15 0x8>;
interrupt-parent = <&ipic>;dfsrr;};[EMAIL
PROTECTED] {cell-index = <0>;compatible = "fsl,spi";
reg = <0x7000 0x1000>;interrupts = <16 0x8>;
interrupt-parent = <&ipic>;mode = "cpu";};/* phy
type (ULPI, UTMI, UTMI_WIDE, SERIAL) */[EMAIL PROTECTED] {
compatible = "fsl-usb2-dr";reg = <0x23000 0x1000>;
#address-cells = <1>;#size-cells = <0>;interrupt-parent
= <&ipic>;interrupts = <38 0x8>;phy_type = "utmi_wide";
};[EMAIL PROTECTED] {#address-cells = <1>;
#size-cells = <0>;compatible = "fsl,gianfar-mdio";reg
= <0x24520 0x20>;phy1: [EMAIL PROTECTED] {
interrupt-parent = <&ipic>;interrupts = <19 0x8>;
reg = <0x1>;device_type = "ethernet-phy";};
phy4: [EMAIL PROTECTED] {
Re: ifconfig MPC8313
Ronald Madrid wrote: I'm guessing by device tree you mean the .dts file? I'm using a modified version of the mpc8313erdb.dts with minor changes (to the local bus only). Here is a copy of it. OK, according to that device tree, eth0 is associated with PHY address 1. Is that correct on your board? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is broken
Every arch/ppc defconfig I built today failed. Someone broke it. On a related note, arch/ppc defconfig doesn't even configure anymore; common_defconfig was removed, but it is still the default. What config should we use as default now? Josh, I'll look into the build failure now. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: ifconfig MPC8313
I don't know, where would I find that out? Sorry, I'm still kind of new to this. Ron > Date: Tue, 6 May 2008 16:35:38 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: linuxppc-dev@ozlabs.org > Subject: Re: ifconfig MPC8313 > > Ronald Madrid wrote: > > I'm guessing by device tree you mean the .dts file? I'm using a > > modified version of the mpc8313erdb.dts with minor changes (to the local > > bus only). Here is a copy of it. > > OK, according to that device tree, eth0 is associated with PHY address > 1. Is that correct on your board? > > -Scott _ Stay in touch when you're away with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_messenger_052008___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ifconfig MPC8313
Ronald Madrid wrote: I don't know, where would I find that out? Sorry, I'm still kind of new to this. In the documentation/schematics/designer's-head of your custom board. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is broken
On Tue, 6 May 2008 23:39:34 +0200 Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > Every arch/ppc defconfig I built today failed. Someone broke it. > > On a related note, arch/ppc defconfig doesn't even configure anymore; > common_defconfig was removed, but it is still the default. What config > should we use as default now? I'd be willing to guess that the answer is "nothing". You're welcome to use ebony_defconfig but that's just as much unmaintained as the rest of arch/ppc and only builds when someone doesn't break it. > Josh, I'll look into the build failure now. Masochist ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: ifconfig MPC8313
I believe that it is zero. Is that valid? Ron > Date: Tue, 6 May 2008 16:43:57 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: linuxppc-dev@ozlabs.org > Subject: Re: ifconfig MPC8313 > > Ronald Madrid wrote: > > I don't know, where would I find that out? > > > > Sorry, I'm still kind of new to this. > > In the documentation/schematics/designer's-head of your custom board. > > -Scott _ With Windows Live for mobile, your contacts travel with you. http://www.windowslive.com/mobile/overview.html?ocid=TXT_TAGLM_WL_Refresh_mobile_052008___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ifconfig MPC8313
Ronald Madrid wrote: I believe that it is zero. Is that valid? FWIH, it's not recommended, as it's interpreted as a broadcast address in some cases. However, if that's the way the board is, then go ahead and put a zero in the phy node's reg property. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is broken
On a related note, arch/ppc defconfig doesn't even configure anymore; common_defconfig was removed, but it is still the default. What config should we use as default now? I'd be willing to guess that the answer is "nothing". Plain "defconfig" should use _something_. Something that still exists, even. You're welcome to use ebony_defconfig Yeah, that's what I use again now. but that's just as much unmaintained as the rest of arch/ppc and only builds when someone doesn't break it. That's more often than "never even starts to build" ;-) Josh, I'll look into the build failure now. Masochist ;) Sadist. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: ifconfig MPC8313
Thank you, that seems to have worked. I can now ping and whatnot. One question though. I used the linux v2.6.20 that came with the BSP for the MPC8313ERDB and the ethernet worked. Was there a bug earlier that would have allowed this default .dts to work with my phy address of '0'? I was rather baffled with this problem as the two dts files seemed to be more or less functionally identical (2.6.20 from BSP vs. 2.6.25) Ron > Date: Tue, 6 May 2008 17:04:21 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: linuxppc-dev@ozlabs.org > Subject: Re: ifconfig MPC8313 > > Ronald Madrid wrote: > > I believe that it is zero. Is that valid? > > FWIH, it's not recommended, as it's interpreted as a broadcast address > in some cases. However, if that's the way the board is, then go ahead > and put a zero in the phy node's reg property. > > -Scott _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
Now back to the first an bigger problem : currently, I have an "old" U-boot and I have written myself a dts file. Problem is : ethernet does not work, but that's not a mac-address problem, but something else that I do not understand yet. The symptom is I get ip route add default via 192.168.85.33 dev eth0 RTNETLINK answers: Network is unreachable I surmise this is because my eth0 does not become up, and I surmise again this is because there is no driver selected to drive the phy. In my arch/ppc setup this was automagically handled by [EMAIL PROTECTED]:1 IIRC Is there something I can put in my dts file to activate a driver for my phy ? Best regards This slipped under my radar, and I'm only just now finding it again. Have your issues been resolved? If not, could you send a bit more of the boot log? There should be a little more if the PHY was not found. If you were operating with a fixed PHY setup before, then the generic PHY driver (which will automatically bind to your PHY) should suffice unless your MDIO bus is broken. Andy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] ppc: Include in kernel/ppc_ksyms.c
It needs it: arch/ppc/kernel/ppc_ksyms.c:152: error: '__flush_icache_range' undeclared here (not in a function) and a few more like that. Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]> --- arch/ppc/kernel/ppc_ksyms.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c index 16ac11c..602c268 100644 --- a/arch/ppc/kernel/ppc_ksyms.c +++ b/arch/ppc/kernel/ppc_ksyms.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include -- 1.5.5.23.g2a5f.dirty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Don't run prom_init_check for arch/ppc builds
arch/ppc doesn't have prom_init.o (anymore). Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]> --- arch/powerpc/kernel/Makefile |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index d14cebf..2346d27 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -105,6 +105,9 @@ PHONY += systbl_chk systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i $(call cmd,systbl_chk) + +ifeq ($(CONFIG_PPC_MERGE),y) + $(obj)/built-in.o: prom_init_check quiet_cmd_prom_init_check = CALL$< @@ -114,4 +117,7 @@ PHONY += prom_init_check prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o $(call cmd,prom_init_check) +endif + + clean-files := vmlinux.lds -- 1.5.5.23.g2a5f.dirty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] ppc: Use ebony_defconfig for defconfig
We used to use common_defconfig, but it was removed some time ago. Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]> --- arch/ppc/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ppc/Makefile b/arch/ppc/Makefile index 8df7f0e..2352d13 100644 --- a/arch/ppc/Makefile +++ b/arch/ppc/Makefile @@ -43,7 +43,7 @@ KBUILD_AFLAGS += $(cpu-as-y) KBUILD_CFLAGS += $(cpu-as-y) # Default to the common case. -KBUILD_DEFCONFIG := common_defconfig +KBUILD_DEFCONFIG := ebony_defconfig head-y := arch/ppc/kernel/head.o head-$(CONFIG_8xx) := arch/ppc/kernel/head_8xx.o -- 1.5.5.23.g2a5f.dirty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fix arch/ppc builds
These three trivial patches make arch/ppc build again. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for Analogue & Micro ASP837E board
On Tue, 6 May 2008 08:37:16 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
/;
> > +
> > +/ {
> > + model = "ASP8347E";
> > + compatible = "ASP8347E";
>
> "analogue-and-micro, ASP8347E";
Fair enough.
> > + memory {
> > + device_type = "memory";
> > + reg = <0x 0x800>; // 128MB at 0
>
> is memory really fixed on this board or does the bootloader set this
> if, dynamic make it <0 0>
It's fixed as far as I know.
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + ranges = <0x0 0xff00 0xff10>;
>
> this is wrong, size should be like 0x10
Agreed - typo !
> > + enet0: [EMAIL PROTECTED] {
> > + cell-index = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <0x24000 0x1000>;
> > + local-mac-address = [ 00 08 e5 11 32 33 ];
> > + interrupts = <32 0x8 33 0x8 34 0x8>;
> > + interrupt-parent = <&ipic>;
> > + phy-handle = <&phy0>;
> > + linux,network-index = <0>;
>
> you shouldn't need this anymore. we should be using the aliases.
Aliases sound good to me. Don't know too much about how this should be defined
in a dts though, do you have an example I could use as a base for reference ?
Cheers.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] Fix bogus paca->_current initialization
When doing lockdep, I had two patches to initialize paca->_current early. One bogus, and one correct. Unfortunately both got merged as the bad one ended up being part of the main lockdep patch by mistake. This causes memory corruption at boot. This patch removes the offending code. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- arch/powerpc/kernel/head_64.S |4 1 file changed, 4 deletions(-) --- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-05-07 09:54:17.0 +1000 +++ linux-work/arch/powerpc/kernel/head_64.S2008-05-07 09:54:23.0 +1000 @@ -1517,10 +1517,6 @@ _INIT_STATIC(start_here_multiplatform) addir2,r2,0x4000 add r2,r2,r26 - /* Set initial ptr to current */ - LOAD_REG_IMMEDIATE(r4, init_task) - std r4,PACACURRENT(r13) - /* Do very early kernel initializations, including initial hash table, * stab and slb setup before we turn on relocation. */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Document when printk is useable
When debugging early boot problems, it's common to sprinkle printk's
all over the place. However, on powerpc 64 bits, this can lead to
memory corruption if done too early due to the PACA pointer and
lockdep core not being initialized.
This adds some comments to early_setup() that document when it is
safe to do so in order to save time to whoever has to debug that
stuff next.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup_64.c |4
1 file changed, 4 insertions(+)
--- linux-work.orig/arch/powerpc/kernel/setup_64.c 2008-05-07
09:54:52.0 +1000
+++ linux-work/arch/powerpc/kernel/setup_64.c 2008-05-07 09:56:31.0
+1000
@@ -170,6 +170,8 @@ void __init setup_paca(int cpu)
void __init early_setup(unsigned long dt_ptr)
{
+ /* printk is _NOT_ safe to use here ! --- */
+
/* Fill in any unititialised pacas */
initialise_pacas();
@@ -185,6 +187,8 @@ void __init early_setup(unsigned long dt
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
+ /* printk is now safe to use --- */
+
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Initialize lockdep earlier
This moves lockdep_init() to before udbg_early_init() as the later
can call things that acquire spinlocks etc... This also makes printk
safer to use earlier.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup_64.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/setup_64.c 2008-05-07
10:23:35.0 +1000
+++ linux-work/arch/powerpc/kernel/setup_64.c 2008-05-07 10:23:45.0
+1000
@@ -181,14 +181,14 @@ void __init early_setup(unsigned long dt
/* Assume we're on cpu 0 for now. Don't write to the paca yet! */
setup_paca(0);
- /* Enable early debugging if any specified (see udbg.h) */
- udbg_early_init();
-
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
/* printk is now safe to use --- */
+ /* Enable early debugging if any specified (see udbg.h) */
+ udbg_early_init();
+
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
jffs2 on imx21ads board
hi all,
I m using imx21ads board, Bootloader is Redboot.
linux is linux-2.6.22 version. Board with Jffs2 root filesystem as root is
not working.
But Ramdisk booting is working...so i tried to mount jffs2 root file system
after
booting board with ramdisk using mount command. It boots up with some error
message as given below.
With df command it shows 100%...
mx27# cat /proc/mtd
dev:size erasesize name
mtd0: 0004 0001 "Bootloader"
mtd1: 0020 0004 "nor.Kernel1"
mtd2: 0020 0004 "nor.kernel2"
mtd3: 00d0 0004 "nor.rootfs1"
mtd4: 00d0 0004 "nor.rootfs2"
mtd5: 0004 0004 "Parameter"
mtd6: 3000 0001 "FIS directory"
mtd7: 1000 0001 "Redboot config"
mx27# cd /dev/
/dev/input/ /dev/net//dev/pts//dev/shm/
mx27# mount -t jffs2 /dev/mtdblock3 /mnt
<6>MTDSB: dev_name "/dev/mtdblock3"
[ 27.82] MTDSB: path_lookup() returned 0, inode c3c50100
[ 27.82] MTDSB: New superblock for device 3 ("nor.rootfs1")
mx27# [ 30.24] Erase at 0x00b8 failed immediately: -EROFS. Is the
sector locked?
[ 30.24] Erase at 0x00b4 failed immediately: -EROFS. Is the sector
locked?
[ 30.25] Erase at 0x00b0 failed immediately: -EROFS. Is the sector
locked?
[ 30.26] Erase at 0x00ac failed immediately: -EROFS. Is the sector
locked?
[ 30.27] Erase at 0x00a8 failed immediately: -EROFS. Is the sector
locked?
[ 30.27] Erase at 0x00a4 failed immediately: -EROFS. Is the sector
locked?
[ 30.28] Erase at 0x00a0 failed immediately: -EROFS. Is the sector
locked?
[ 30.29] Erase at 0x009c failed immediately: -EROFS. Is the sector
locked?
[ 30.30] Erase at 0x0098 failed immediately: -EROFS. Is the sector
locked?
[ 30.30] Erase at 0x0094 failed immediately: -EROFS. Is the sector
locked?
[ 30.31] Erase at 0x0090 failed immediately: -EROFS. Is the sector
locked?
[ 30.32] Erase at 0x008c failed immediately: -EROFS. Is the sector
locked?
[ 30.33] Erase at 0x0088 failed immediately: -EROFS. Is the sector
locked?
[ 30.34] Erase at 0x0084 failed immediately: -EROFS. Is the sector
locked?
[ 30.34] Erase at 0x0080 failed immediately: -EROFS. Is the sector
locked?
[ 30.35] Erase at 0x007c failed immediately: -EROFS. Is the sector
locked?
[ 30.36] Erase at 0x0078 failed immediately: -EROFS. Is the sector
locked?
[ 30.37] Erase at 0x0074 failed immediately: -EROFS. Is the sector
locked?
[ 30.37] Erase at 0x0070 failed immediately: -EROFS. Is the sector
locked?
[ 30.38] Erase at 0x006c failed immediately: -EROFS. Is the sector
locked?
[ 30.39] Erase at 0x0068 failed immediately: -EROFS. Is the sector
locked?
[ 30.40] Erase at 0x0064 failed immediately: -EROFS. Is the sector
locked?
[ 30.41] Erase at 0x0060 failed immediately: -EROFS. Is the sector
locked?
[ 30.41] Erase at 0x005c failed immediately: -EROFS. Is the sector
locked?
[ 30.42] Erase at 0x0058 failed immediately: -EROFS. Is the sector
locked?
[ 30.43] Erase at 0x0054 failed immediately: -EROFS. Is the sector
locked?
[ 30.44] Erase at 0x0050 failed immediately: -EROFS. Is the sector
locked?
[ 30.44] Erase at 0x004c failed immediately: -EROFS. Is the sector
locked?
mx27#
mx27#
mx27# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram0 7280 4963 1948 72% /
df: /mnt/rwfs: No such file or directory
rwfs 512 232 280 45% /tmp
rwfs 512 232 280 45% /etc
rwfs 512 232 280 45% /var
shm 31560 0 31560 0% /dev/shm
/dev/mtdblock3 13312 13312 0 100% /mnt
mx27#
mx27#
waiting for inputs
tnks,
Nethra
--
View this message in context:
http://www.nabble.com/jffs2-on-imx21ads-board-tp17093824p17093824.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: jffs2 on imx21ads board
In message <[EMAIL PROTECTED]> you wrote: > > I m using imx21ads board, Bootloader is Redboot. > linux is linux-2.6.22 version. Board with Jffs2 root filesystem as root is > not working. Argh.. You really are ignoring all good advice, aren't you? After you have been told that this posting wa soff topic on the U-Boot list and your hsould ask on the ARM mailing list instead, you now post it again on a PowerPC list? What makes you think i.MX21 related topics would fit here? You are off topic again! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Human beings were created by water to transport it uphill. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
