* Re: 2.6.25-rc3-mm1 ppc64 boot hang
From: Andrew Morton @ 2008-03-05 21:54 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Matthew Wilcox, linuxppc-dev, linux-kernel
In-Reply-To: <1204752855.7939.42.camel@dyn9047017100.beaverton.ibm.com>
On Wed, 05 Mar 2008 13:34:14 -0800
Badari Pulavarty <pbadari@gmail.com> wrote:
> On Tue, 2008-03-04 at 01:19 -0800, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc3/2.6.25-rc3-mm1/
> >
>
> Hi Andrew,
>
> Not able to boot 2.6.25-rc3-mm1 my ppc64 box.
> 2.6.25-rc2-mm1 and 2.6.25-rc3 boots fine.
>
> I applied slab.c fix also.
>
> Any other known issues ? My config file attached.
> Here are the messages on the console.
The semaphore consolidation code enables interrupts early in boot, when it
shouldn't. This tends to make powerpc blow up. Could be that this is what
you're hitting.
Matthew, is this ging to be fixed soon?
Thanks.
^ permalink raw reply
* Re: 2.6.25-rc3-mm1 ppc64 boot hang
From: Badari Pulavarty @ 2008-03-05 22:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: Matthew Wilcox, linuxppc-dev, lkml
In-Reply-To: <20080305135425.c8ebf8e4.akpm@linux-foundation.org>
On Wed, 2008-03-05 at 13:54 -0800, Andrew Morton wrote:
> On Wed, 05 Mar 2008 13:34:14 -0800
> Badari Pulavarty <pbadari@gmail.com> wrote:
>
> > On Tue, 2008-03-04 at 01:19 -0800, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc3/2.6.25-rc3-mm1/
> > >
> >
> > Hi Andrew,
> >
> > Not able to boot 2.6.25-rc3-mm1 my ppc64 box.
> > 2.6.25-rc2-mm1 and 2.6.25-rc3 boots fine.
> >
> > I applied slab.c fix also.
> >
> > Any other known issues ? My config file attached.
> > Here are the messages on the console.
>
> The semaphore consolidation code enables interrupts early in boot, when it
> shouldn't. This tends to make powerpc blow up. Could be that this is what
> you're hitting.
>
> Matthew, is this ging to be fixed soon?
Yes. I just backed out git-semaphore.patch and machine booted fine.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Gabriel Paubert @ 2008-03-05 22:59 UTC (permalink / raw)
To: Stefan Richter
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <47CC0C95.1030709@s5r6.in-berlin.de>
On Mon, Mar 03, 2008 at 03:35:01PM +0100, Stefan Richter wrote:
> Gabriel Paubert wrote:
> > I have a Pismo which I use on a virtually
> > daily basis (and about to remove the last remnants of MacOS on it).
> > However I have disabled Firewire because it would not sleep and wake
> > up properly.
> >
> > I can test it on Wednesday with a 5GB fireflly disk from 2001.
> >
> > Please tell me which configuration options I need to set for
> > Firewire (which stack, etc...).
>
> Config options of the new stack:
> FIREWIRE=m
> FIREWIRE_OHCI=m
> FIREWIRE_SBP2=m
>
> Config options of the old stack:
> IEEE1394=m
> IEEE1394_OHCI1394=m
> IEEE1394_SBP2=m
> and if desired also the other drivers for raw userspace access,
> isochronous I/O (alias video1394 even though it can also be used for
> other purposes), DV I/O, and IPv4 over 1394.
>
> The two SBP2 drivers also need SCSI and BLK_DEV_SD a.k.a. SCSI disk
> support or/and BLK_DEV_SR a.k.a. SCSI CDROM support.
>
> You can also set the options to Y but I find loadable and hence
> unloadable modules more practical... 'cause I unload and reload them all
> the time. :-)
Indeed, although this machine typically had non-modular kernels, I
compiled one for these tests.
For now I have only tested the new stack with a 6 year old 1.8" disk
and everything works, including suspend to RAM. The kernel is 2.6.25-rc4
plus additional pull from linux1394-2.6.git: 2.6.25-rc4-00032-g8d36ba4.
Thanks a lot.
Regards,
Gabriel
P.S: it seems that something broke in the APM emulation around rc2
on this machine, battery level reads at -1% from /proc/apm.
> Caveats:
> - You could build and install both stacks but should then blacklist
> at least one of ohci1394 or firewire-ohci. Better keep it simple
> and install only one of the stacks at a time.
> - We still have a serious use-after-free bug in the new stack. This
> may lead to kernel panic if the kernel was build with (slab? or
> page allocation?) debugging enabled.
> Users of IP over 1394 and pro/semipro audio still need the old stack.
> Users of video should stick with the stack which their distribution has
> enabled because our support in the lowlevel libraries libraw1394 and
> libdc1394 to switch between the stacks is not quite comfortable yet.
>
> Suspend (to RAM) and resume worked for me [TM] when I last tested them
> with each stack. I tested i586/APM, x86-64/ACPI, and last weekend ppc32
> on 1st generation PowerBook G4. I haven't tested hibernate (to disk)
> and restore yet.
I have never used suspend to disk on this machine. Suspend to RAM
failed when ieee1394 was loaded (or built-in) since 2.6.22 or so.
For now I have only tested the new stack with a 6 year old 1.8" disk
and everything works, including suspend to RAM. The kernel is 2.6.25-rc4
plus additional pull from linux1394-2.6.git: 2.6.25-rc4-00032-g8d36ba4.
Thanks a lot.
Regards,
Gabriel
P.S: it seems that something broke in the APM emulation around rc2
on this machine, battery level reads at -1% from /proc/apm.
^ permalink raw reply
* Re: 2.6.25-rc3-mm1 ppc64 boot hang
From: Stephen Rothwell @ 2008-03-05 23:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox, linuxppc-dev, linux-kernel, Badari Pulavarty
In-Reply-To: <20080305135425.c8ebf8e4.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]
Hi Andrew,
On Wed, 5 Mar 2008 13:54:25 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> The semaphore consolidation code enables interrupts early in boot, when it
> shouldn't. This tends to make powerpc blow up. Could be that this is what
> you're hitting.
>
> Matthew, is this ging to be fixed soon?
There is a new version of these patches in the current linux-next tree ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-03-05 23:26 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <20080305225902.GA27985@iram.es>
Gabriel Paubert wrote:
>>> I have a Pismo which I use on a virtually
>>> daily basis (and about to remove the last remnants of MacOS on it).
>>> However I have disabled Firewire because it would not sleep and wake
>>> up properly.
...
> For now I have only tested the new stack with a 6 year old 1.8" disk
> and everything works, including suspend to RAM. The kernel is 2.6.25-rc4
> plus additional pull from linux1394-2.6.git: 2.6.25-rc4-00032-g8d36ba4.
That's great. Thanks for testing.
--
Stefan Richter
-=====-==--- --== --==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-05 23:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1204748068.21545.209.camel@pasglop>
Hi Ben,
On Thu, Mar 06, 2008 at 07:14:28AM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-03-05 at 17:15 +0100, Philippe De Muyter wrote:
> >
> > I asked the guy who designed the hardware, and if I understand
> > correctly :
> >
> > - the i/o and memory resources of the pci device are connected to the
> > pci bus
> > - the interrupts are directly connected to the MPIC
> >
> > Can I describe that in the dts file ?
>
> Sure, you can describe pretty much any interrupt routing, provided that
> we know -how- (ie. where) they are connected. We also need to know the
They are connected directly to the pic-part of the mpc8540 just as
described in the .c file in the other mail.
> idsel of the devices. (The later we can deduce from lspci done in
> arch/ppc).
Does this (boot error messages in the not-working arch/powerpc kernel) :
PCI: Cannot allocate resource region 0 of device 0000:00:12.0
PCI: Cannot allocate resource region 0 of device 0000:00:12.1
PCI: Cannot allocate resource region 0 of device 0000:00:12.2
PCI: Cannot allocate resource region 1 of device 0000:00:12.2
or this (/proc/bus/pci in the working arch/pcc kernel)
Sorry, I am at home now and cannot access my board :)
or this (boot info messages from working arch/pcc kernel) :
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[55] MMIO=[9f7fd800-9f7fdfff] Max Packet=[2048] IR/IT contexts=[4/8]
...
Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
...
Yenta TI: socket 0000:00:12.0, mfunc 0x00001b00, devctl 0x66
Yenta TI: socket 0000:00:12.0 probing PCI interrupt failed, trying to fix
Yenta TI: socket 0000:00:12.0 falling back to parallel PCI interrupts
Yenta TI: socket 0000:00:12.0 parallel PCI interrupts ok
Yenta: ISA IRQ mask 0x0000, PCI irq 53
...
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0x80000000-0x9fffffff: excluding 0x80000000-0x807fffff 0x9f000000-0x9fffffff
pcmcia: registering new device pcmcia0.0
Yenta TI: socket 0000:00:12.1 parallel PCI interrupts ok
Yenta: ISA IRQ mask 0x0000, PCI irq 54
Socket status: 30000086
or this (U-boot info message) :
PCI Scan: Found Bus 0, Device 18, Function 0
00 12 104c ac46 0607 ff
PCI Scan: Found Bus 0, Device 18, Function 1
00 12 104c ac46 0607 ff
PCI Scan: Found Bus 0, Device 18, Function 2
00 12 104c 802a 0c00 00
and this (/proc/interrupts on a working system)
CPU0
25: 0 OpenPIC Level gfar_interrupt
26: 245 OpenPIC Level serial
27: 0 OpenPIC Level i2c-mpc
53: 18797 OpenPIC Level yenta, ide0
54: 1 OpenPIC Level yenta
55: 79 OpenPIC Level ohci1394
BAD: 0
help ?
Philippe
> > >
> > > Or are you doing some swizzling ?
> > >
> > > Also, I would need to know how those external IRQs are connected to
> > the MPIC,
> > > I don't have the spec of that chip here. Hrm. Somebody from
> > freescale can
> > > help him here ?
> > >
> > > It's also not clear to me what your interrupts 9 10 and 11 are since
> > you
> > > seem to only talk about PIRQA...D which is only 4 lines ..
> > >
> > > So at this stage, that's not enough information. We need to know
> > exactly how
> > > you have wired things on your board, and somebody from fsl needs to
> > tell
> > > me how the ExtIrq are routed to the MPIC on that guy.
> > >
> > > Once that's done, you seem to have grasped the interrupt map... for
> > any
> > > device or slot, you provide the mapping between idsel/pirq line on
> > one side,
> > > and mpic interrupt & sense on the other. For PCI, sense is always 1
> > for an
> > > mpic so you mostly have to check your actual MPIC source numbers.
> > >
> > > >From your .dts, I see you've been doing some swizzling of slots
> > using
> > > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> > >
> > > Ben.
> > >
> > > >
> > > > /*
> > ************************************************************************ */
> > > >
> > --- ./arch/ppc/platforms/85xx/mpc85xx_ads_common.hbk 2008-01-24
> > 22:58:37.000000000 +0000
> > > > +++ ./arch/ppc/platforms/85xx/mpc85xx_ads_common.h 2008-02-20
> > 16:36:07.000000000 +0000
> > > > @@ -29,10 +29,17 @@
> > > > extern void mpc85xx_ads_map_io(void) __init;
> > > >
> > > > /* PCI interrupt controller */
> > > > +#ifdef CONFIG_MEIP_8540
> > > > +#define PIRQA MPC85xx_IRQ_EXT5
> > > > +#define PIRQB MPC85xx_IRQ_EXT6
> > > > +#define PIRQC MPC85xx_IRQ_EXT7
> > > > +#define PIRQD MPC85xx_IRQ_EXT8
> > > > +#else
> > > > #define PIRQA MPC85xx_IRQ_EXT1
> > > > #define PIRQB MPC85xx_IRQ_EXT2
> > > > #define PIRQC MPC85xx_IRQ_EXT3
> > > > #define PIRQD MPC85xx_IRQ_EXT4
> > > > +#endif
> > > >
> > > > #define MPC85XX_PCI1_LOWER_IO 0x00000000
> > > > #define MPC85XX_PCI1_UPPER_IO 0x00ffffff
> >
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-05 23:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Philippe De Muyter
In-Reply-To: <47CECB21.3060704@freescale.com>
> >>From your .dts, I see you've been doing some swizzling of slots using
> > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
>
> No, those correspond to the EXT1-4 that are the other side of the #ifdef
> for this board in arch/ppc. :-)
Yes, that's what I was thinking. So that's what he got wrong in
his .dts.
Philippe, you need to fix those numbers so they map your EXTIRQ.
(that is 1 -> 5, 2 -> 6, etc... )
And of course you need to make sure you have the right routing to the
chip. it's funny the way you keep providing all sort of info but -never-
the one we actually asked for :-)
We basically, to help you, need to know for each PCI device connected to
the SoC, or PCI slot if you have such, which address line is used for
IDSEL, and to which MPIC interrupt inputs.
Once you have given us that, we'll be able to help.
It appears that just looking at the arch/ppc code is a bit too messy and
confusing (and not necessarily right).
In addition, you will also need to do proper interrupt routing for you
other devices (RTC, etc...) but we can look at that separately.
Ben.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Benjamin Herrenschmidt @ 2008-03-06 0:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox, linuxppc-dev, Michael Neuling, linux-kernel,
Kamalesh Babulal
In-Reply-To: <20080304103350.12d26560.akpm@linux-foundation.org>
> Yes, we are - it's the semaphore rewrite which is doing this in
> start_kernel(). It's being discussed.
>
> Enabling interrupts too early on powerpc was discovered to be fatal on
> powerpc years ago. It looks like that remains the case.
Regarding these issues. I could make it non fatal and just WARN_ON,
provided that I have a way to differentiate legal vs. illegal calls
to local_irq_enable(). We already have that function mostly out of
line in C code due to our lazy irq disabling scheme, so the overhead of
testing some global kernel state would be minimum here.
However, I don't see anything around init/main.c:start_kernel() that I
can use. What do you reckon here we should do ? Add some kind of global
we set before calling local_irq_enable() ? Or make early_boot_irqs_on()
do that generically
It's currently defined as an empty inline without CONFIG_TRACE_IRQFLAGS
but we could make it set a flag instead.
I'm pretty sure other archs have similar problems, especially in the
embedded world where you are booted with random junk firmwares that may
leave devices, interrupt controllers etc... in random state, and
enabling incoming IRQs before the arch code properly initializes the
main interrupt controller can be fatal. I know at least of an ARM board
I worked on a while ago that had a similar issues.
On ppc32, unfortunately, our local_irq_enable/restore are nice inlines
that whack the appropriate MSR bits directly, thus adding a test for a
global flag would add some bloat/overhead that I'd like to avoid, at
least until we decide to also do lazy disabling on those, if ever...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC 4xx: Add dcri_clrset() for locked read/modify/write functionality
From: Benjamin Herrenschmidt @ 2008-03-06 0:06 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080305183804.GA21760@ru.mvista.com>
On Wed, 2008-03-05 at 21:38 +0300, Valentine Barshak wrote:
> This adds dcri_clrset() macro which does read/modify/write
> on indirect dcr registers while holding indirect dcr lock.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> ---
> include/asm-powerpc/dcr-native.h | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+)
>
> --- linux-2.6.orig/include/asm-powerpc/dcr-native.h 2008-03-05 17:32:31.000000000 +0300
> +++ linux-2.6/include/asm-powerpc/dcr-native.h 2008-03-05 17:53:16.000000000 +0300
> @@ -82,6 +82,19 @@ static inline void __mtdcri(int base_add
> spin_unlock_irqrestore(&dcr_ind_lock, flags);
> }
>
> +static inline void __dcri_clrset(int base_addr, int base_data, int reg,
> + unsigned clr, unsigned set)
> +{
> + unsigned long flags;
> + unsigned int val;
> +
> + spin_lock_irqsave(&dcr_ind_lock, flags);
> + __mtdcr(base_addr, reg);
> + val = (__mfdcr(base_data) & ~clr) | set;
> + __mtdcr(base_data, val);
> + spin_unlock_irqrestore(&dcr_ind_lock, flags);
> +}
> +
> #define mfdcri(base, reg) __mfdcri(DCRN_ ## base ## _CONFIG_ADDR, \
> DCRN_ ## base ## _CONFIG_DATA, \
> reg)
> @@ -90,6 +103,10 @@ static inline void __mtdcri(int base_add
> DCRN_ ## base ## _CONFIG_DATA, \
> reg, data)
>
> +#define dcri_clrset(base, reg, clr, set) __dcri_clrset(DCRN_ ## base ## _CONFIG_ADDR, \
> + DCRN_ ## base ## _CONFIG_DATA, \
> + reg, clr, set)
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DCR_NATIVE_H */
^ permalink raw reply
* Re: [PATCH 3/4] Emerson KSI8560 device tree
From: David Gibson @ 2008-03-06 0:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080305173128.GA12443@loki.buserror.net>
On Wed, Mar 05, 2008 at 11:31:28AM -0600, Scott Wood wrote:
> On Wed, Mar 05, 2008 at 10:29:40AM +1100, David Gibson wrote:
> > On Tue, Mar 04, 2008 at 07:35:40PM +0300, Alexandr Smirnov wrote:
> > > + device_type = "network";
> > > + model = "TSEC";
> > > + compatible = "gianfar";
> >
> > This still looks like the old binding.
>
> Unfortunately, only the mdio node has a new binding. The gianfar driver
> itself (or rather the glue code in fsl_soc.c) still insists on the above.
Oh. Yuck :(.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] The MPC83xx family doesn't support performance monitor instructions
From: Gerald Van Baren @ 2008-03-06 0:33 UTC (permalink / raw)
To: linuxppc-dev, galak
"Errata to MPC8349EA PowerQUICC[tm] II Pro Integrated Host Processor Family
Reference Manual, Rev. 1" (Freescale)
Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
---
Hi Kumar,
Please apply this fix to 2.6.25rc4 if possible. Without this
patch, the PPC_83xx family configuration is broken (will not compile).
arch/powerpc/platforms/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 0afd225..a578b96 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -22,7 +22,6 @@ config PPC_83xx
select FSL_SOC
select MPC83xx
select IPIC
- select FSL_EMB_PERFMON
config PPC_86xx
bool "Freescale 86xx"
--
1.5.4.1
^ permalink raw reply related
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Andrew Morton @ 2008-03-06 0:44 UTC (permalink / raw)
To: benh; +Cc: willy, linuxppc-dev, mikey, linux-kernel, kamalesh
In-Reply-To: <1204761811.21545.238.camel@pasglop>
On Thu, 06 Mar 2008 11:03:31 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Yes, we are - it's the semaphore rewrite which is doing this in
> > start_kernel(). It's being discussed.
> >
> > Enabling interrupts too early on powerpc was discovered to be fatal on
> > powerpc years ago. It looks like that remains the case.
>
> Regarding these issues. I could make it non fatal and just WARN_ON,
> provided that I have a way to differentiate legal vs. illegal calls
> to local_irq_enable().
And local_irq_restore() and various other things.
> We already have that function mostly out of
> line in C code due to our lazy irq disabling scheme, so the overhead of
> testing some global kernel state would be minimum here.
>
> However, I don't see anything around init/main.c:start_kernel() that I
> can use. What do you reckon here we should do ? Add some kind of global
> we set before calling local_irq_enable() ? Or make early_boot_irqs_on()
> do that generically
>
> It's currently defined as an empty inline without CONFIG_TRACE_IRQFLAGS
> but we could make it set a flag instead.
>
> I'm pretty sure other archs have similar problems, especially in the
> embedded world where you are booted with random junk firmwares that may
> leave devices, interrupt controllers etc... in random state, and
> enabling incoming IRQs before the arch code properly initializes the
> main interrupt controller can be fatal. I know at least of an ARM board
> I worked on a while ago that had a similar issues.
>
> On ppc32, unfortunately, our local_irq_enable/restore are nice inlines
> that whack the appropriate MSR bits directly, thus adding a test for a
> global flag would add some bloat/overhead that I'd like to avoid, at
> least until we decide to also do lazy disabling on those, if ever...
I'd have thought that the way to do this would be to add it to lockdep -
lockdep already has all the infrastructure and code sites to do this.
Set some special flag saying its-ok-to-enable-interrupts-now and test that
in lockdep.
akpm:/usr/src/25> grep LOCKDEP arch/powerpc/Kconfig
akpm:/usr/src/25>
losers ;)
Still, doing it for
akpm:/usr/src/25> grep -l LOCKDEP arch/*/Kconfig
arch/arm/Kconfig
arch/avr32/Kconfig
arch/mips/Kconfig
arch/s390/Kconfig
arch/sh/Kconfig
arch/sparc64/Kconfig
arch/um/Kconfig
arch/x86/Kconfig
should give pretty good coverage.
^ permalink raw reply
* Re: [Pasemi-linux] [patch 1/6] pasemi_mac: Move RX/TX section enablement to dma_lib
From: Michael Ellerman @ 2008-03-06 0:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, pasemi-linux, jgarzik, linuxppc-dev
In-Reply-To: <20080305182100.GA8411@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]
On Wed, 2008-03-05 at 12:21 -0600, Olof Johansson wrote:
> On Tue, Feb 26, 2008 at 08:14:20AM -0600, Olof Johansson wrote:
> > Hi,
> >
> > On Tue, Feb 26, 2008 at 10:46:06PM +1100, Michael Ellerman wrote:
> > > On Wed, 2008-02-20 at 20:57 -0600, Olof Johansson wrote:
> > > > + i = 1000;
> > > > + pasemi_write_dma_reg(PAS_DMA_COM_RXCMD, 0);
> > > > + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_RXSTA) & 1))
> > > > + i--;
> > > > + if (i < 0)
> > > > + printk(KERN_INFO "Warning: Could not disable RX section\n");
> > > > +
> > > > + i = 1000;
> > > > + pasemi_write_dma_reg(PAS_DMA_COM_TXCMD, 0);
> > > > + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_TXSTA) & 1))
> > > > + i--;
> > >
> > > This kind of caught my eye, is it still going to work when the next core
> > > is twice as fast?
>
> FYI; I've commited in this change, rest of the patch is identical.
>
> diff --git a/arch/powerpc/platforms/pasemi/dma_lib.c b/arch/powerpc/platforms/pasemi/dma_lib.c
> index c529d8d..48cb7c9 100644
> --- a/arch/powerpc/platforms/pasemi/dma_lib.c
> +++ b/arch/powerpc/platforms/pasemi/dma_lib.c
> @@ -17,6 +17,7 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> */
>
> +#include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> @@ -410,6 +411,7 @@ int pasemi_dma_init(void)
> struct resource res;
> struct device_node *dn;
> int i, intf, err = 0;
> + unsigned long timeout;
> u32 tmp;
>
> if (!machine_is(pasemi))
> @@ -478,6 +480,34 @@ int pasemi_dma_init(void)
> for (i = 0; i < MAX_RXCH; i++)
> __set_bit(i, rxch_free);
>
> + timeout = jiffies + HZ;
> + pasemi_write_dma_reg(PAS_DMA_COM_RXCMD, 0);
> + while (pasemi_read_dma_reg(PAS_DMA_COM_RXSTA) & 1) {
> + if (time_after(jiffies, timeout)) {
> + pr_warning("Warning: Could not disable RX section\n");
> + break;
> + }
> + }
> +
> + timeout = jiffies + HZ;
> + pasemi_write_dma_reg(PAS_DMA_COM_TXCMD, 0);
> + while (pasemi_read_dma_reg(PAS_DMA_COM_TXSTA) & 1) {
> + if (time_after(jiffies, timeout)) {
> + pr_warning("Warning: Could not disable TX section\n");
> + break;
> + }
> + }
I like that a lot better :)
Ooo, someone beat me to adding pr_warning() - nice.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Benjamin Herrenschmidt @ 2008-03-06 0:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: willy, linuxppc-dev, mikey, linux-kernel, kamalesh
In-Reply-To: <20080305164438.fff7bb7c.akpm@linux-foundation.org>
On Wed, 2008-03-05 at 16:44 -0800, Andrew Morton wrote:
> On Thu, 06 Mar 2008 11:03:31 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > > Yes, we are - it's the semaphore rewrite which is doing this in
> > > start_kernel(). It's being discussed.
> > >
> > > Enabling interrupts too early on powerpc was discovered to be fatal on
> > > powerpc years ago. It looks like that remains the case.
> >
> > Regarding these issues. I could make it non fatal and just WARN_ON,
> > provided that I have a way to differentiate legal vs. illegal calls
> > to local_irq_enable().
>
> And local_irq_restore() and various other things.
Yes, on powerpc 64 bits, they all go down to one C function that does
the lazy enable/disable, so it would be easy to deal with. 32 bits
doesn't have it that simple tho.
> I'd have thought that the way to do this would be to add it to lockdep -
> lockdep already has all the infrastructure and code sites to do this.
>
> Set some special flag saying its-ok-to-enable-interrupts-now and test that
> in lockdep.
Ok.
> akpm:/usr/src/25> grep LOCKDEP arch/powerpc/Kconfig
> akpm:/usr/src/25>
>
> losers ;)
I have lockdep patches for powerpc 32 and 64 bits. They aren't upstream
yet as they need a bit more beating up and there's at least one machine
that doesn't seem to like them, so I'm working on just that. That's a
good idea to add the test to lockdep tho, I'll see what I can do.
> Still, doing it for
>
> akpm:/usr/src/25> grep -l LOCKDEP arch/*/Kconfig
> arch/arm/Kconfig
> arch/avr32/Kconfig
> arch/mips/Kconfig
> arch/s390/Kconfig
> arch/sh/Kconfig
> arch/sparc64/Kconfig
> arch/um/Kconfig
> arch/x86/Kconfig
>
> should give pretty good coverage.
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC 4xx: Add dcri_clrset() for locked read/modify/write functionality
From: Josh Boyer @ 2008-03-06 1:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1204761978.21545.240.camel@pasglop>
On Thu, 06 Mar 2008 11:06:18 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Wed, 2008-03-05 at 21:38 +0300, Valentine Barshak wrote:
> > This adds dcri_clrset() macro which does read/modify/write
> > on indirect dcr registers while holding indirect dcr lock.
> >
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Indeed, looks good. Valentine, are you going to rework your EMAC patch
to use this?
josh
^ permalink raw reply
* dtc: Make dtc_open_file() die() if unable to open requested file
From: David Gibson @ 2008-03-06 1:16 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
All current callers of dtc_open_file() immediately die() if it returns
an error. In a non-interative tool like dtc, it's hard to see what
you could sensibly do to recover from a failure to open an input file
in any case.
Therefore, make dtc_open_file() itself die() if there's an error
opening the requested file. This removes the need for error checking
at the callsites, and ensures a consistent error message in all cases.
While we're at it, change the rror message from fstree.c when we fail
to open the input directory to match dtc_open_file()'s error message.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-lexer.l | 3 ---
dtc.c | 4 ----
fstree.c | 4 ++--
srcpos.c | 11 ++++-------
4 files changed, 6 insertions(+), 16 deletions(-)
Index: dtc/dtc-lexer.l
===================================================================
--- dtc.orig/dtc-lexer.l 2008-03-06 12:07:32.000000000 +1100
+++ dtc/dtc-lexer.l 2008-03-06 12:08:22.000000000 +1100
@@ -259,9 +259,6 @@
}
newfile = dtc_open_file(filename, searchptr);
- if (!newfile)
- die("Couldn't open \"%s\": %s", filename, strerror(errno));
-
incl_file = xmalloc(sizeof(struct incl_file));
Index: dtc/fstree.c
===================================================================
--- dtc.orig/fstree.c 2008-03-06 12:07:32.000000000 +1100
+++ dtc/fstree.c 2008-03-06 12:08:22.000000000 +1100
@@ -31,8 +31,8 @@
struct node *tree;
d = opendir(dirname);
- if (! d)
- die("opendir(): %s\n", strerror(errno));
+ if (!d)
+ die("Couldn't opendir() \"%s\": %s\n", dirname, strerror(errno));
tree = build_node(NULL, NULL);
Index: dtc/srcpos.c
===================================================================
--- dtc.orig/srcpos.c 2008-03-06 12:07:32.000000000 +1100
+++ dtc/srcpos.c 2008-03-06 12:08:22.000000000 +1100
@@ -82,9 +82,8 @@
if (fname[0] == '/') {
file->file = fopen(fname, "r");
-
if (!file->file)
- goto out;
+ goto fail;
file->name = strdup(fname);
return file;
@@ -98,15 +97,13 @@
return file;
if (errno != ENOENT)
- goto out;
+ goto fail;
search = search->next;
}
-out:
- free(file->dir);
- free(file);
- return NULL;
+fail:
+ die("Couldn't open \"%s\": %s\n", fname, strerror(errno));
}
void dtc_close_file(struct dtc_file *file)
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2008-03-06 12:08:34.000000000 +1100
+++ dtc/dtc.c 2008-03-06 12:08:38.000000000 +1100
@@ -193,10 +193,6 @@
bi = dt_from_fs(arg);
} else if(streq(inform, "dtb")) {
inf = dtc_open_file(arg, NULL);
- if (!inf)
- die("Couldn't open \"%s\": %s\n", arg,
- strerror(errno));
-
bi = dt_from_blob(inf->file);
} else {
die("Unknown input format \"%s\"\n", inform);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Remove ugly include stack abuse
From: David Gibson @ 2008-03-06 1:45 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently, dt_from_source() uses push_input_file() to set up the
initial input file for the lexer. That sounds sensible - put the
outermost input file at the bottom of the stack - until you realise
that what it *actually* does is pushes the current, uninitialized,
lexer input state onto the stack, then sets up the new lexer input.
That necessitates an extra check in pop_input_file(), rather than
signalling termination in the natural way when the include stack is
empty, it has to check when it pops the bogus uninitialized state off
the stack. Ick.
With that fixed, push_input_file(), pop_input_file() and
incl_file_stack itself become local to the lexer, so make them static.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-lexer.l | 12 ++++++------
srcpos.h | 3 ---
treesource.c | 3 ++-
3 files changed, 8 insertions(+), 10 deletions(-)
Index: dtc/treesource.c
===================================================================
--- dtc.orig/treesource.c 2008-03-05 16:14:54.000000000 +1100
+++ dtc/treesource.c 2008-03-06 12:24:49.000000000 +1100
@@ -32,7 +32,8 @@
the_boot_info = NULL;
treesource_error = 0;
- push_input_file(fname);
+ srcpos_file = dtc_open_file(fname, NULL);
+ yyin = srcpos_file->file;
if (yyparse() != 0)
return NULL;
Index: dtc/dtc-lexer.l
===================================================================
--- dtc.orig/dtc-lexer.l 2008-03-06 12:25:24.000000000 +1100
+++ dtc/dtc-lexer.l 2008-03-06 12:43:52.000000000 +1100
@@ -52,6 +52,9 @@
DPRINT("<V1>\n"); \
BEGIN(V1); \
}
+
+static void push_input_file(const char *filename);
+static int pop_input_file(void);
%}
%%
@@ -229,7 +232,7 @@
struct incl_file *prev;
};
-struct incl_file *incl_file_stack;
+static struct incl_file *incl_file_stack;
/*
@@ -240,7 +243,7 @@
static int incl_depth = 0;
-void push_input_file(const char *filename)
+static void push_input_file(const char *filename)
{
struct incl_file *incl_file;
struct dtc_file *newfile;
@@ -282,7 +285,7 @@
}
-int pop_input_file(void)
+static int pop_input_file(void)
{
struct incl_file *incl_file;
@@ -312,8 +315,5 @@
*/
free(incl_file);
- if (YY_CURRENT_BUFFER == 0)
- return 0;
-
return 1;
}
Index: dtc/srcpos.h
===================================================================
--- dtc.orig/srcpos.h 2008-03-06 12:43:23.000000000 +1100
+++ dtc/srcpos.h 2008-03-06 12:43:25.000000000 +1100
@@ -75,9 +75,6 @@
extern struct dtc_file *srcpos_file;
-extern void push_input_file(const char *filename);
-extern int pop_input_file(void);
-
struct search_path {
const char *dir; /* NULL for current directory */
struct search_path *prev, *next;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH] math-emu: delete PowerPC old math-emu headers
From: Liu Yu @ 2008-03-06 3:05 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1204713892.21545.199.camel@pasglop>
>=20
> On Wed, 2008-03-05 at 17:02 +0800, Liu Yu wrote:
> > Use common headers as a replacement.
> > The Common headers are located in "include/math-emu/", they=20
> are used=20
> > by multiple platforms such as s390, sparc, alpha.
> >=20
> > As the common headers have more developers, they are more=20
> popular and=20
> > more stable.
> >=20
> > In fact, PowerPC old math-emu headers cannot handle float point=20
> > exceptions exactly while the common headers can.
>=20
> That sounds like an excellent idea. However, were you able to=20
> run some kind of test suite to verify that the emulation=20
> works properly ?
>=20
Not yet, for I don't have the right environment. :-(
We have a patch to handle MPC85xx SPE.
The patch is not yet a part of kernel and used to adopt PowerPC math-emu
headers=20
like current math-emu for PowerPC FP does.=20
When we ran TestFloat which is a famous FP test suite to test the SPE
patch,
it reported numerous errors and most of them concerned wrong FP
exception flags.
After we change the SPE patch to the common math-emu headers, the result
of TestFloat are splendid.
So I think the same change should be done on current PowerPC FP
math-emu.
^ permalink raw reply
* dtc: Abolish asize field of struct data
From: David Gibson @ 2008-03-06 4:48 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
The asize field in struct data is a hangover from the early days when
a struct data was sometimes allowed to refer to a static chunk of
memory rather than a malloc()ed block.
That's long gone, since the lifetime issues were far more trouble than
it was worth, so get rid of the asize field.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2008-03-06 15:43:56.000000000 +1100
+++ dtc/dtc.h 2008-03-06 15:44:06.000000000 +1100
@@ -118,7 +118,6 @@
struct data {
int len;
char *val;
- int asize;
struct marker *markers;
};
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2008-03-06 15:44:27.000000000 +1100
+++ dtc/data.c 2008-03-06 15:45:01.000000000 +1100
@@ -32,8 +32,6 @@
m = nm;
}
- assert(!d.val || d.asize);
-
if (d.val)
free(d.val);
}
@@ -43,9 +41,6 @@
struct data nd;
int newsize;
- /* we must start with an allocated datum */
- assert(!d.val || d.asize);
-
if (xlen == 0)
return d;
@@ -56,11 +51,8 @@
while ((d.len + xlen) > newsize)
newsize *= 2;
- nd.asize = newsize;
nd.val = xrealloc(d.val, newsize);
- assert(nd.asize >= (d.len + xlen));
-
return nd;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RAW Sockets - HDLC or Ethernet
From: Russell McGuire @ 2008-03-06 9:24 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]
Anyone,
Yet another mysterious question, at least to me.
I have written to simple utilities to send and receive a file / data through
a newly created driver, HDLC using an MPC8360E.
Though I doubt this question is limited to that specific HW.
The main question is that everything I send though device HDLC0 I can
immediately read from HDLC0 even though logically there is no connection
there. It as if the kernel is immediately allowing me to read from the same
device, what a separate application just wrote.???
HOW CAN THIS BE?
Details:
I have two applications: send and receive. (pseudo code as follows)
Send opens a socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)).
And binds it (AF_PACKET, ETH_P_HLDC, if_index(hdlc0))
Receive opens a socket to the same device
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))
bind(AF_PACKET, ETH_P_ALL, if_index(hdlc0)
Note they are opening the same device.
Now if I send anything through the send application, I immediately receive
it via the receive application??
Note, entirely separate processes!
Note, there is NO hardware loopback, this should be a dead end, and I should
get nothing back at least as far as HW is concerned.
What am I missing, that causes all my TX data to show up immediately in the
RX app? Note I have verified my HDLC drier is not actually receiving
anything, so is there something in the kernel that is bridging the TX / RX
paths, or am I just missing the function of this? If so how can I use RAW
mode, while not mixing this, or at least keeping them separate in the
applications?
-Russ
[-- Attachment #2: Type: text/html, Size: 9225 bytes --]
^ permalink raw reply
* How to boot kernel in JTAG mode
From: learn linux @ 2008-03-06 10:20 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Heydeck
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
Hi,
I am new to this linux and jtag. I want to set up the my board in jtag
mode so that I could boot the kernel in jtag mode and try to debug the
kernel.
I need a general information how to set it up.
Thanks in advance,
Sudeep.
[-- Attachment #2: Type: text/html, Size: 321 bytes --]
^ permalink raw reply
* RE: I2S driver
From: Angelo @ 2008-03-06 10:27 UTC (permalink / raw)
To: Pedro Luis D. L.; +Cc: linuxppc-embedded
In-Reply-To: <BLU106-W10231BF41CAF09DAD5DBC0CA110@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
how can i take these headers file?
> Pedro wrote:
> #include <sysdev/bestcomm/bestcomm.h>
> #include <sysdev/bestcomm/gen_bd.h>
> #include <sysdev/bestcomm/bestcomm_priv.h>
I try to download some kernel version (2.6.23 and 2.6.24) but there aren't any library of bestcomm.
Many thanks.
---------------------------------
Inviato da Yahoo! Mail.
La web mail più usata al mondo.
[-- Attachment #2: Type: text/html, Size: 751 bytes --]
^ permalink raw reply
* [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Li Yang @ 2008-03-06 10:42 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Li Yang, paulus
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 66 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8378_mds.dts | 66 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8379_mds.dts | 66 +++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/mpc837x_mds.c | 8 +--
4 files changed, 201 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 677a061..3aac8b7 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -47,6 +47,72 @@
reg = <0x00000000 0x20000000>; // 512MB at 0
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8377-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ // booting from NOR flash
+ ranges = <0 0x0 0xfe000000 0x02000000
+ 1 0x0 0xf8000000 0x00008000
+ 3 0x0 0xe0600000 0x00008000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0 0x0 0x2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ u-boot@0 {
+ reg = <0x0 0x100000>;
+ read-only;
+ };
+
+ fs@100000 {
+ reg = <0x100000 0x800000>;
+ };
+
+ kernel@1d00000 {
+ reg = <0x1d00000 0x200000>;
+ };
+
+ dtb@1f00000 {
+ reg = <0x1f00000 0x100000>;
+ };
+ };
+
+ bcsr@1,0 {
+ reg = <1 0x0 0x8000>;
+ compatible = "fsl,mpc837xmds-bcsr";
+ };
+
+ nand@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8377-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <3 0x0 0x8000>;
+
+ u-boot@0 {
+ reg = <0x0 0x100000>;
+ read-only;
+ };
+
+ kernel@100000 {
+ reg = <0x100000 0x300000>;
+ };
+
+ fs@400000 {
+ reg = <0x400000 0x1c00000>;
+ };
+ };
+ };
+
soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/boot/dts/mpc8378_mds.dts
index 3f9e9fe..2496e19 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -47,6 +47,72 @@
reg = <0x00000000 0x20000000>; // 512MB at 0
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8378-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ // booting from NOR flash
+ ranges = <0 0x0 0xfe000000 0x02000000
+ 1 0x0 0xf8000000 0x00008000
+ 3 0x0 0xe0600000 0x00008000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0 0x0 0x2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ u-boot@0 {
+ reg = <0x0 0x100000>;
+ read-only;
+ };
+
+ fs@100000 {
+ reg = <0x100000 0x800000>;
+ };
+
+ kernel@1d00000 {
+ reg = <0x1d00000 0x200000>;
+ };
+
+ dtb@1f00000 {
+ reg = <0x1f00000 0x100000>;
+ };
+ };
+
+ bcsr@1,0 {
+ reg = <1 0x0 0x8000>;
+ compatible = "fsl,mpc837xmds-bcsr";
+ };
+
+ nand@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8378-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <3 0x0 0x8000>;
+
+ u-boot@0 {
+ reg = <0x0 0x100000>;
+ read-only;
+ };
+
+ kernel@100000 {
+ reg = <0x100000 0x300000>;
+ };
+
+ fs@400000 {
+ reg = <0x400000 0x1c00000>;
+ };
+ };
+ };
+
soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts b/arch/powerpc/boot/dts/mpc8379_mds.dts
index 36c1c13..5ae4644 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
@@ -47,6 +47,72 @@
reg = <0x00000000 0x20000000>; // 512MB at 0
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8379-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ // booting from NOR flash
+ ranges = <0 0x0 0xfe000000 0x02000000
+ 1 0x0 0xf8000000 0x00008000
+ 3 0x0 0xe0600000 0x00008000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0 0x0 0x2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ u-boot@0 {
+ reg = <0x0 0x100000>;
+ read-only;
+ };
+
+ fs@100000 {
+ reg = <0x100000 0x800000>;
+ };
+
+ kernel@1d00000 {
+ reg = <0x1d00000 0x200000>;
+ };
+
+ dtb@1f00000 {
+ reg = <0x1f00000 0x100000>;
+ };
+ };
+
+ bcsr@1,0 {
+ reg = <1 0x0 0x8000>;
+ compatible = "fsl,mpc837xmds-bcsr";
+ };
+
+ nand@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8379-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <3 0x0 0x8000>;
+
+ u-boot@0 {
+ reg = <0x0 0x100000>;
+ read-only;
+ };
+
+ kernel@100000 {
+ reg = <0x100000 0x300000>;
+ };
+
+ fs@400000 {
+ reg = <0x400000 0x1c00000>;
+ };
+ };
+ };
+
soc@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 8a9c269..1f4b7e8 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -39,12 +39,9 @@ static int mpc837xmds_usb_cfg(void)
if (ret)
return ret;
/* Map BCSR area */
- np = of_find_node_by_name(NULL, "bcsr");
+ np = of_find_compatible_node(NULL, NULL, "fsl,mpc837xmds-bcsr");
if (np) {
- struct resource res;
-
- of_address_to_resource(np, 0, &res);
- bcsr_regs = ioremap(res.start, res.end - res.start + 1);
+ bcsr_regs = of_iomap(np, 0);
of_node_put(np);
}
if (!bcsr_regs)
@@ -96,6 +93,7 @@ static void __init mpc837x_mds_setup_arch(void)
static struct of_device_id mpc837x_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
+ { .compatible = "simple-bus", },
{},
};
--
1.5.4.rc4
^ permalink raw reply related
* Re: [PATCH] PowerPC 4xx: Add dcri_clrset() for locked read/modify/write functionality
From: Valentine Barshak @ 2008-03-06 11:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080305191216.5089f696@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 06 Mar 2008 11:06:18 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Wed, 2008-03-05 at 21:38 +0300, Valentine Barshak wrote:
>>> This adds dcri_clrset() macro which does read/modify/write
>>> on indirect dcr registers while holding indirect dcr lock.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Indeed, looks good. Valentine, are you going to rework your EMAC patch
> to use this?
>
> josh
Yes, I was going to update the pcie stuff and rework the emac patches.
Thanks,
Valentine.
^ permalink raw reply
* [PATCH 1/2] fix wrong USB phy type in mpc837xmds dts
From: Li Yang @ 2008-03-06 10:42 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Li Yang, paulus
Due to chip constraint MPC837x USB DR module can only use
ULPI and serial PHY interfaces. The patch fixes the wrong
type in dts.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 4 ++--
arch/powerpc/boot/dts/mpc8378_mds.dts | 4 ++--
arch/powerpc/boot/dts/mpc8379_mds.dts | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
index a3637ff..677a061 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -91,7 +91,6 @@
mode = "cpu";
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
@@ -99,7 +98,8 @@
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
- phy_type = "utmi_wide";
+ dr_mode = "host";
+ phy_type = "ulpi";
};
mdio@24520 {
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/boot/dts/mpc8378_mds.dts
index 533e9b0..3f9e9fe 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -91,7 +91,6 @@
mode = "cpu";
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
@@ -99,7 +98,8 @@
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
- phy_type = "utmi_wide";
+ dr_mode = "host";
+ phy_type = "ulpi";
};
mdio@24520 {
diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts b/arch/powerpc/boot/dts/mpc8379_mds.dts
index c270685..36c1c13 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
@@ -91,7 +91,6 @@
mode = "cpu";
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
@@ -99,7 +98,8 @@
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
- phy_type = "utmi_wide";
+ dr_mode = "host";
+ phy_type = "ulpi";
};
mdio@24520 {
--
1.5.4.rc4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox